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fJower ~upplles and Service 


iSBC™ 680/iSBC 681 
MUL TISTORE™ USER SYSTEM PACKAGE 


• Complete system package for user· 
selected Intel® iSBC boards and up to 
two 8" peripheral drives 


• Available in table·top (iSBC 680 pack· 


age) or rack·mount (iSBC 681 package) 
configurations 


• Holds up to six iSBC boards compatible 


with the MULTIBUS® system bus 
• Designed to meet UL safety require· 


ments and FCCIVDE EMI limits 


• Supplies 
: 5, : 12, : 24 VDC to power 


boards and peripheral drives 
• Power supply provides 8 ms of power· 


fail warning, plus a real·time clock 


The iSBC 680/iSBC 681 Multistore 
User System Package products 
make available to the OEM a new way to 


assemble 
his systems 
for those applications 
requiring 
rotating 
memory or other peripherals 
built in the 8" 


ind~stry-standard 
form factor. The Multistore 
package allows 
the OEM to select the iSBC boards required 


for the job, and to independently 
choose 
from a wide variety of peripherals 
to complete 
the system. 
The 
switching 
power 
supply 
provides 
sufficient 
current 
at all voltage 
levels 
to power 
most 
manufacturers' 


drives, 
as well 
as furnishing 
the standard 
MUL T1BUS system 
bus voltages 
to the iSBC boards 
in the 


package's 
cardcage. The appearance 
of the packages 
provides an attractive 
addition 
to the OEM's system, 


while the construction 
allows 
easy access to the interior 
for service. 


J,If'" 
irJ 


Physical Packaging 


PACKAGE 
CONSTRUCTION 
- 
The 
Multistore 


package 
is constructed 
entirely 
of metal, 
and all 


cover 
pieces 
are gasketed 
to completely 
contain 


high-frequency 
noise 
from 
the power 
supply 
and 


the system 
boards within 
the package. 


MOUNTING 
OPTIONS..,.. 
The iSBC 680 package is 


a table-top 
structure; 
the iSBC 681 package is the 


rack-mount 
version with slides attached 
to the side 


panels and a wider trim bezel to cover the mount- 
ing rails. 


COOLING 
- 
The boards and peripherals 
installed 


in the package are cooled 
by air brought 
in at the 
bottom 
of the front 
panel and drawn through 
the 


power supply, with the heated air discharged 
to the 


rear of the package. 


CARDCAGEIBACKPLANE 
- 
The cardcage/back- 


plane accepts 
up to six iSBC boards 
compatible 


with the Intel MUL TIBUS system 
bus (Figure 
1), 


Figure 1. Boards Mounted 
in the Cardcage 
of the 


iSBC 680 Package 


PARALLEL 
PRIORITY 
- 
Up to six 
bus 
masters 


may be installed 
in the package 
because 
of the 


parallel priority 
logic which is an integral part of the 


backplane. 


ENHANCED 
NOISE 
IMMUNITY 
- 
The integrity 
of 
the package 
is enhanced 
by a new backplane 
for 


the system 
boards, 
which 
offers 
improved 
noise 


immunity 
through 
advanced design 
techniques. 


PERIPHERAL 
MOUNTING 
- 
Two 
positions 
are 


provided 
for 
mounting 
of 
peripheral 
drives 
con- 
forming 
to the de facto 
industry 
standard 
for size 


and mounting 
points on 8" peripherals. 
The mount- 
ing system 
provides 
slides 
for the bases 
of the 


drives, allowing 
the drives to be installed/removed 


from the front of the package (Figure 2). 


Blank 
covers 
with 
ventilation 
slots 
are provided 


with 
the package 
for the unused 
peripheral 
posi- 


tions and for those peripherals 
not furnished 
with a 


cosmetic 
cover. 


Figure 2. iSBC 680 Package with Winchester 
Drive 


Pulled Out for Servicing 


System Power 


BASIC 
POWER 
SUPPLY 
- 
The supply 
provided 


with 
the 
package 
is 
an 
advanced-technology 


switching 
power 
supply, 
offering 
large 
current 
capabilities 
over the six 
DC voltages 
supported. 


Sockets 
for drive power are located 
on the power 


supply bulkhead 
at the rear of the peripheral 
cavity 


(Figure 3). 


Figure 
3. 
Power 
Supply 
Showing 
Three 
Power 


Connectors 
(Two 
for Peripherals, 
One 


for the Cardcage/Backplane) 


inter 


INTERNATIONAL 
ACCEPTANCE 
- 
The package 
is a UL-recognized 
component, 
and it has been 
designed 
to meet the safety 
requirements 
of CSA 
and VDE. 


MEETS EMI STANDARDS 
- 
The FCC standards 
for conducted 
and radiated 
EMI (electromagnetic 


interference), 
as well 
as the 
VDE 
requirements 


(0871/0875), 
are met by the package. 


POWER·FAIUAUTO·RESTART 
SYSTEM 
- 
The 
package gives the user a set of logic signals 
pro- 


viding advanced warning of power failures 
and pro- 
tection 
for battery 
backed-up 
memory 
as the DC 
voltages 
fall. 
It also 
furnishes 
a real-time 
clock 
derived 
from 
the 
line 
frequency, 
thus 
ensuring 
long-term 
stability 
in user time-keeping. 


User Interface 


USER CONTROLS 
- 
At the front 
of the package 


the user has access 
to both the AC power switch 


(with 
integral 
circuit 
breaker) and controls 
and in- 


dicators 
for 
the 
microcomputer 
system 
itself. 
"RESET" 
and 
"INTERRUPT" 
switches 
are 
pro- 
vided, 
along 
with 
"RUN" 
and "HALT" 
LED indi- 
cators. 


DEVICE INTERFACE - 
With the package designed 


for maximum 
suppression 
of both 
EMI and ESD 


(electrostatic 
discharge) 
the 
preferred 
interface 


between 
the installed 
boards and external 
devices 


is 
with 
shielded 
cables 
isolated 
through 
user- 


supplied 
connectors 
installed 
in the panel provided 


at the rear of the package (Figure 
4). The six cut- 


outs, 
sized 
for 
50-pin 
connectors, 
are furnished 


with individual 
cover plates. 


Figure 4. iSBC 680 Package Showing 
External 


Device Connection 
Panel 


Input Power 


Frequency 
- 
47-66 Hz 


Voltage 
- 
90-126 VAC/180-252 
VAC, single phase 


(user-selectable). 


Periodic 
and Random 
Deviation 
(PARD) - 
50 mV 
peak-to-peak, 
all outputs. 


Output 
Regulation 
(Combined 
Line and Load) - 
± 1% 
under 
any conditions 
of AC input 
voltage 
variation 
(within operational 
range) and output 
load 
change. 


Line Transient 
Tolerance 
- 
A signal of up to 1000 
VDC, with a pulse width of up to 50 fls, will have no 
affect 
on system 
operation. 


Output 
Power 


Power 
Fail 
Indication 
- 
PFINI 
is generated 
ap- 
proximately 
8 ms 
after 
the 
input 
drops 
below 
90/180 VAC. PFINI is available on the P2 connector 
of the cardcage/backplane 
for generation 
of an in- 


terrupt.The 
± 24 VDC outputs 
will go to zero within 


1 ms of issuance 
of PFIN/; the ± 5 and ± 12 VDC 


outputs 
will remain within 
specification 
for at least 


8 ms, after which MPROI will go true to protect 
non- 


volatile 
memories 
from 
being 
written 
into 
as DC 


power fails. 


System Clock - 
The power supply 
provides a 2 x 


line 
frequency 
clock 
output, 
available 
on the 
P2 


connector 
of the cardcage/backplane. 


Current' 
Typical 
Peripheral 
Nominal 
Power Requirements' 


Voltage 
(Max 
8" 
Diskette 
Amps) 
Winchester 
Drive 


+5 
30.0 
5.1 
1.0 


-5 
2.0 
0.25 
0.07 


+ 12 
2.9 
- 
- 


-12 
3.0 
0.7 
- 
+24 
7.8 
4.0 
1.8 


-24 
1.6 
- 
- 


NOTES: 
1. The maximum power available from the supply, from all out- 


puts, is 300 watts. 


2. These are worst-case data, drawn from manufacturers' data 


sheets. 


Physical 
Characteristics 
(Figure 5) 


Width 
- 
16.8/19.0 in. (42.5/48.3 cm) 
iSBC 680liSBC 
681 Packages 


Length 
- 
21.5 in. (54.6 cm) 
. 


Height 
- 
12.2 in. (31.1 cm) 


Weight 
- 
40 Ib (18.2 kg) (approximate) 


Board Slots 
- 
Six @0.665 in. on centers 
between 
boards. 
The board in the top slot may contain 
any 


iSBX and/or 
iSBC MULTIMODULE 
boards. 


Peripheral 
Size - 
The drives 
must 
fit 
within 
an 
envelope 
8.55 in. high by 14.25 in. deep by 4.65 in. 
wide. 


Data Separator 
Board Location 
- 
A space is pro- 


vided 
within 
the package 
to secure 
a Winchester 
drive data separator 
board, if required. 


Environmental 
Characteristics 


Ambient 
(Inlet) 
Air 
Temperature 
- 
The 
inlet 
air 


temperature, 
with 
peripheral 
drives 
installed, 
may 
not exceed 
35·C. This is for the protection 
of the 
peripherals, 
as both diskette 
and Winchester 
drives 
have 
ambient 
maximums 
of 
40·C 
in 
most 
in- 
stances. 


Humidity 
- 
20% to 80% 
RH, non·condensing 
for 


the chassis 
and typical 
peripheral 
content. 


NOTE: The photos of the Multistore packages in tRis data sheet 
show boards, an 8" Winchester hard disk drive, and an 8" flexi- 
ble disk drive installed. The packages do not include these 
boards and peripherals; they are shown in the photographs to il- 
lustrate physical arrangements in the Mullistore package. 


Equipment 
Supplied 


iSBC 
680 Chassis 
- 
Includes 
table-top 
package 


with 
aluminum 
sheet 
metal, 6-slot 
cardcage/back· 


plane, 
combination 
On/Off 
switch 
and 
circuit 
breaker, 
peripheral 
mounting 
hardware 
(user must 


supply 
power 
and signal 
cabling 
for 
peripherals), 


and power supply 
with AC power cord. 


iSBC 681 Chassis 
- 
Same as iSBC 680 chassis, 


plus rack·mount 
chassis 
slides 
and wider 
bezel. 


Reference 
Manual 


162432 
- 
iSBCTM 680/681 
Multistore™ 
Chassis 


Hardware 
Reference 
Manual (NOT SUPPLIED) 


Manuals 
may be ordered from any Intel sales repre- 


sentative, 
distributor 
office 
or from Intel Literature 


Department, 
3065 Bowers Avenue, Santa Clara, CA 


95051. 


Part Number 


SBC 680 


Description 


Multistore 
User System 
Package 
(Table-Top) 


Multistore 
User System 
Package 
(Rack·Mount) 


inter 


iSBC 665/iSBC 645™ 
SYSTEM CHASSIS AND POWER SUPPLY 


• Intel MULTIBUSTMsystem 
bus 4-slot 


packaging 


• Complete 
package 
of rack-mounting, 


cooling, 
controls, 
and power 


• Advanced 
110 watt switching 
power 


supply 
generates 
± 5, ± 12 VDC 


• Meets U.S. and International 
EMI and 


safety 
requirements 


• Wide AC voltage 
margins 
keep systems 


running 
during 
"brownouts" 


• Front panel switches, 
indicators, 
and 


adjustments 
for operational 
and service 


convenience 


• Power sense circuitry 
interrupts 


system 
6 msec prior to power failure 


The Intel iSBC 665liSBC 645 Chassis 
system 
provides 
the MULTIBUS system 
bus user with a compact 
set 


of products 
offering 
new standards 
in 4-slot 
rack-mount 
packaging. 
A high-efficiency 
switching 
power 


supply 
allows 
use of 
115/230 VAC (+ 15/- 
20%), 
with 
large 
surge 
and noise 
components, 
to deliver 


smooth, 
stable 
DC power to the OEM board load. Advanced 
power-fail 
sense and restart 
logic 
gives the 


user sufficient 
time to bring the system 
to an orderly 
shutdown 
in the event of AC mains power failure. 


Mechanical 
design 
features 
include 
EMI suppression 
and a retainer/cover 
for system 
boards and I/O edge 


connectors. 
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The following 
are trademarks 
of 
Intel 
Corporation 
and 
may 
be used 
only 
to describe 
Intel 
products: 
CREDIT. 
Index, 
Intel, 
In site. 
Intellee, 
Library 
Manager, 
MegachassiS, 


Mlcromap, 
MUL TIBUS, 
PROMPT, 
UPI, ,IIScope, 
Prom ware, 
MeS, 
ICE, iRMX, 
iSBC, 
iSaX, 
MUL T1MODULE 
and ieS, and the combination 
of MeS, 
ICE, iSeC, 
jSBX. 
iRMX 
or ieS, and 


a numerical 
sullix. 
Inlel 
Corporation 
assumes 
no responsibility 
lor the use of any circuitry 
other 
than circuitry 
embodied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are 


implied. 


iSBC 665™ System Chassis 


The iSBC 665 Chassis is a complete 
micro- 
computer package providing four board slots in a 
3.5" vertical space. 


RACK MOUNT 
PACKAGE 


The iSBC 665 Chassis mounts in a 19" EIA stan- 
dard rack, using its front panel and hangers at the 
rear of the chassis to secure it to both sets of rails 
in the cabinet. If slide mounting is preferred, a tray 
with slides should be used as a platform for the 
chassis. The physical integrity of the system is 
enhanced by addition of a connector retainer at 
the (rear-facing) opening of the cardcage. 


The fan on the power supply is utilized to draw 
ambient air across the boards prior to its being 
used to cool the supply. 


FRONT PANEL 


The front panel of the iSBC 665 Chassis forms a 
complete control center for the system installed 
in the chassis (see Figure 1). 


iSBC 645 Power Supply 


The 110-watt supply of the iSBC 665 Chassis is 
designed to provide advanced features to the Intel 
system builder who faces complex power supply 
and chassis requirements. 


Figure 
1. iSBC 665™ Chassis 
Front 
Panel Controls 


Table 1. iSBC 665™ ChassisJiSBC 
645™ Power 


Supply 
Control 
Panel Functions 


Label 
Function 


Controls 
DC aNlaFF 
Controls all DC power to the chas- 
sis. 
RESET 
Generates RESETIsignal to pin 14 
of 
P1 (MULTIBUS system 
bus) 


backplane. 


INTRPT 
Generates INTI signal to pin 42 of 
P1. 


Indicators 
HALT, RUN 
Indicate 
status 
of 
system 
CPU 
board. 
ACaN 
Indicates AC power present in sup- 
ply (AC power switch is located at 
the rear of the supply). 


aV 
Indicates power supply shut-down 
due to an overvoltage condition on 
+ 5 or ± 12 VDC outputs. 


AC La 
Indicates that AC voltage is below 
the operating range and the supply 
has shut down. 


Adjustments 
+5 
Adjusts + 5 VDC output voltage. 


-V 
Adjusts 
negative adjustable 
volt- 


age; set to - 5 VDC at the factory. 


AC La 
Adjusts 
AC 
sense 
threshold 
at 


which the system generates power- 
fail signals; set to 88/176 
VAC at 


factory. 


The supply is a UL-recognized component; the 
supplylchassis combination is also designed to 
meet the safety requirements of CSA (Canada) 
and VDE (Germany) as industrial, computer, and 
office equipment.1 
I 


The FCC standards for conducted and radiated 
EMI (electromagnetic interference) are met by the 
supply, thus the chassis packaging will enhance 
the OEM's efforts to assemble systems which 
must comply with the FCC Part 15 Rules. In addi- 
tion, the supplylchassis design meets the most 
stringent VDE requirements (087110875)for con- 
ducted and radiated EM1.1 


NOTE: 
1. CSA and VDE testing have not been officially 
completed; 


testing 
at independent laboratories indicates that these 


safety 
and EMI requirements 
are met. Official 
testing 


should be completed in late 1981. 


BROWNOUT 
PROTECTION 


The wide 
AC voltage 
input 
range 
allows 
micro- 
computer 
systems 
packaged 
in the 
chassis 
to 


function 
normally 
at extremely 
low 
AC voltage 


supply 
levels. 


In the event of a complete 
power failure, 
an inter- 


rupt is generated 
6 ms prior to the supply's 
issu- 


ing a subsequent 
memory 
protect 
signal, 
giving 


sufficient 
time for execution 
of a user program 
to 


bring the entire 
system 
to an orderly 
shut-down. 


The supply 
provides 
immunity 
for the system 
from 


the high-voltage 
transient 
surges and spikes seen 


in AC power 
systems. 
The supply 
itself 
provides 


this 
isolation 
with 
a metal-oxide 
varistor 
(MOV) 


and line filter 
in the input circuitry. 


POWER LINE CLOCK 


A clock 
signal 
is developed 
from 
the AC line at 


twice 
the 
line 
frequency; 
this 
gives 
the 
system 


user an extremely 
accurate 
time base. 


Electrical 
Characteristics 


INPUT POWER 
Frequency: 
47-66 
Hz 


Voltage: 
115/230 
VAC Single 
Phase 


Range: 
90 to 126 VAC/180 to 252 VAC 


'Consumption 
(Max.): 230 watts 


OUTPUT POWER 


Current 
2 
Current 


Nominal 
(Max. 
Limit 
Overvoltage 


Voltage 
Point 
Protection3 
Amps) 
(Amps) 


+5 
15 
18.75 
5.25 to 6.25 


+ 12 
3 
3.75 
12.6 to 15.0 


- 12 
1 
1.25 
- 12.6 to - 15.0 


- Adjustable4 
1 
1.25 
N/A 


NOTES: 
2. Total output power is 110 watts; a maximum of 128 watts is 
available, but proper operation of the power·fail circuitry 
is 


not guaranteed above 110 watts. 


3. A minimum load is required on the + 5 VDC output; this load 


must be at least V, the sum of the loads (in watts) of the 
remaining three outputs. 
4. - 2.5 to - 12 VDC; factory set to - 5 VDC. 


OUTPUT 
REGULATION 
(COMBINED 
LINE 
AND 


LOAD) - 
± 1% under any conditions 
of AC mains 


voltage 
variation 
(within 
operational 
range) 
and 


output 
load change. 


PERIODIC AND RANDOM 
DEVIATION 
(PARD) - 


50 millivolts 
peak-to-peak, 
all outputs. 


LINE TRANSIENT 
TOLERANCE 
- 
A signal 
of up 


to 
1000 VDC, 
with 
a pulse 
width 
of 
up 
to 
50 


microseconds, 
will 
have no affect 
on operation. 


POWER FAIL INDICATION 
- 
An AC low condi- 


tion 
generates 
ACLO and PFINI after 
AC voltage 


drops 
below 
the 
allowed 
voltage 
range. 
These 


signals 
are 
available 
on 
the 
P2 connector 
to 


generate 
interrupts. 
The DC voltages 
will 
remain 


within 
specifications 
for 
6 milliseconds 
(worst 


case) 
following 
these 
interrupts, 
after 
which 


Memory 
Protect 
(MPRO/) will go true. 


OUTPUT 
VOLTAGE 
TEMPERATURE 
COEFFI· 


CIENT - 
0.03% 
per ·C over the operating 
range. 


SYSTEM 
CLOCK 
- 
2 x 
line 
frequency 
clock 


signal 
available 
on P2 connector. 


Physical 
Characteristics 
(See Figure 3) 


WIDTH - 
19.0 in. (48.3 em) 
LENGTH - 
16.25 in. (41.3 em) 


HEIGHT - 
3.5 in. (8.9 em) 


WEIGHT - 
12.0 Ib (5.4 kg) 


Environmental 
Characteristics 


AMBIENT 
(INLET) 
AIR 
TEMPERATURE 


Chassis: O·C to 55·C; Power Supply: O·C to 65·C 
(Full Rated Output) 


HUMIDITY - 
Up to 95% non-condensing. 


Equipment 
Supplied 


iSBC 665 SYSTEM CHASSIS - 
Includes iSBC 645 


Power Supply, iSBC 604 Modular Cardcagel Back- 
plane, 
connector 
retainer, 
schematics 
for 


cardcage/backplane, 
chassis, and power supply. 


iSBC 645 POWER SUPPLY - 
Includes power sup- 
ply, schematics 
for supply. 


Reference 
Manuals 
(Not Supplied) 


142836 - 
iSBC 665"" System Chassis Hardware 


Reference Manual 


142918 - 
iSBC 645T'" 
Power Supply 
Hardware 


Reference Manual 


9800708 - 
iSBC 
604/614T'" 
Modular 
Cardcagel 


Backplane Hardware Reference Manual 


9088683 - 
Intel MULTIBUS Specification 


Manuals may be ordered from any Intel sales rep- 
resentative, distribution 
office, or from Intel Liter- 


ature 
Department, 
3065 Bowers 
Avenue, Santa 


Clara, California 95051. 
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Figure 3.iSBC 
665!'" System Chassis 


Physical Dimensions 


Part Number 


SBC 665 
SBC 645 


Description 


System Chassis 
Power Supply (110 Watt) 


iSBC®661 
SYSTEM CHASSIS 


• Eight-slot MULTIBUS® chassis with 
parallel priority circuitry 


• UL, FCC and CSA approved for data 
processing equipment 


• 230 watt power supply with power fail 
warning 


• Designed for slide rack mounting or 
bench-top use 


• Extra-wide cardcage slot spacing for 


iSBX™ MULTIMODULE™ board 
clearance 


• Configurable for front or rear access to 


MULTIBUS® circuit boards 


• Five connector ports for 1/0 cabling 


• Operational from 47 Hz to 63 Hz, 


100/120/220/240 
VAC ± 10% 


The iSBC® 661 System Chassis is one of the most advanced 
MULTIBUS® (IEEE 796) packaging 
products. 
It incorpo- 


rates unique usability and service features not found on competitive 
products. This chassis is designed for rack-mount 


or bench-top 
applications 
and reliably operates 
between 
the-ambient 
temperatures 
of DOC to 5DoC. 
Additionally, 


this system chassis 
is certified 
by UL, CSA, and FCC for data processing 
equipment. 


An application 
requiring multiprocessing 
will find this eight-slot MULTIBUS chassis particularly well suited to its needs. 


Parallel priority bus arbitration 
circuitry 
has been integrated 
into the backplane. 
This permits a bus master to reside 
in each slot. Extra-wide 
inter-slot 
spacing 
on the cardcage 
allows the use of plug-on 
MULTIMODULE™ 
boards 


without blocking adjacent slots. For this reason, the iSBC 661 System Chassis provides the slot-functionality 
of most 


16-slot chassis. 
Standard 
logic recognizes 
a system AC power failure and generates 
a TTL signal for use in power- 


down control. 
Additionally, 
current 
limiting 
and over-VOltage protection 
are provided 
at all outputs. 


The following 
are trademarks 
of Intel Corporation 
and may be used onty to describe 
Intel products: 
Intel, ICE. 
iMMX, 
iRMX, 
iSBC, 
iSBX. 
iSXM, 
MUL T18US, 
MULTlCHANNEl 
and MULnMODULE. 


Intel Corporation 
assumes 
no responsibility 
for the use 01 any circuitry other than circuitry embodied 
in an Intel product. 
No other circuit palent 
licenses are implied. 


© INTEL 
CORPORATION, 
1983 
January, 
1983 


1·9 
Order Number: 
210866-001 


inter 


Mechanical Features 


The iSBC 661 System Chassis houses, cools, powers, 
and interconnects 
up to eight iSBC single board com- 
puters and their MULTIMODULE boards for the MULTIBUS 
System Bus. Based on Intel's iSBC 608 Cardcage, 
the 


chassis 
provides 
0.8 inches of board center-te-center 


clearance 
on six slots, and 1.2 inches or more of center- 
to-center clearance 
on two slots. This permits the users 


of standard 
MULTIMODULE 
boards and custom wire- 
wrap boards to plug into the MULTIBUS 
System 
Bus 


without blocking adjacent slots. All slots provide enough 
clearance 
for iSBC MULTIMODULE 
boards, 
and two 


slots can accommodate 
iSBX MULTIMODULE 
boards. 


High-technology 
MULTIBUS 
applications 
requiring 


rack-mount, 
or laboratory 
bench-top 
use will find the 


iSBC 661 System 
Chassis 
ideal. Standard 
19" slide- 
rack mounting 
is possible 
with 
user-provided 
slides 


attached 
to the side panels. 
Slide mounting 
holes are 


provided 
on the chassis for the slide-rails 
listed under 
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User Supplied Options. Rubber feet are included on the 
chassis 
for convenient 
bench-top 
use. 


The chassis is constructed of burnished aluminum which 
has been coated with corrosion-resistant 
chromate. 
It 


contains 
a system control 
module which 
presents 
the 


front panel control switches 
to the user, and holds the 


110 cabling 
bulkhead 
to the rear. The chassis 
has the 


unique feature of being configurable 
for either front or 


rear access to MULTIBUS 
circuit 
boards. 


This is accomplished 
by a simple procedure 
involving 


removal of the system control module, reversing 
it end- 


for-end, 
and re-securing 
it to the chassis. 
The system 


chassis 
is shipped 
in a configuration 
such 
that 
the 


MULTIBUS 
boards are installed 
from the front. 


Electrical Features 


The iSBC 661 System Chassis is powered by the iSBC 
640 power supply. This is a standard 
Intel power sup- 


ply which has been adopted by several MULTIBUS ven- 
dors throughout 
the industry. 
It supplies 
230 watts of 
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FRONT VIEW 
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power, power fail warning, 
and remote sensing 
of + 5 


volts. Its electrical and operational 
parameters 
are listed 


under Specifications. 


The card cage of the iSBC 661 System Chassis 
imple- 
ments a user-changeable 
parallel priority bus arbitration 


scheme 
by using plug-in jumper 
connections. 
Six dif- 
ferent priority schemes are allowed, each scheme fixing 
the priority of the eight MULTIBUS board slots. Bus con- 


tention 
among eight bus-masters 
in a multiprocessing 


environment 
can be be managed 
using this approach. 


Noise minimizing 
ground traces are strategically 
inter- 
leaved between signal and address lines on the system 
bus. This provides 
the enhanced 
noise immunity 
and 


minimized signal-to-signal 
coupling which is particularly 


important 
in high speed, 
high board count microcom- 


puter systems. 


Output 
Current 
Over-Voltage 
Voltage 
Current 
Limits 
Protection 
(max.) 
(amps) 


+12V 
4.5A 
4.7-6.8 
15V± 1V 


+5V 
30.0A 
31.5-45.0 
6.2V ±O.4V 


-5V 
1.75A 
1.8-3.2 
-6.2V 
±O.4V 


-12V 
1.75A 
1.8-3.2 
-15V±1V 


OPERATIONAL 
PARAMETERS 


Input 
AC Voltage 
- 
100/120/220/240 
VAC ± 10% 
(User selects via external 
switch) 


Power-Fail 
Indication 
and Hold-Up 
Time ( triggered 
at 90% of VAC in) - 
TTL O.C. High 3 msec. (min.) 


Output 
Ripple 
and Noise - 
1% Peak-to-Peak 
output 
nominal 
(DC to 0.5 MHz) 


Operational 
Temperature 
- 
O°C to 50°C 


Storage 
Temperature 
- 
- 40°C to 70°C 


Operational 
Humidity 
- 
10% to 85% relative, 
non-condensing 


Remote 
Sensing 
- 
Provided 
for + 5 VDC 


Output 
Transient 
Response 
- 
50 I'sec or less for 
± 50% load change 


PHYSICAL 
CHARACTERISTICS 


Width 
- 
16.95 inches (43.05 cm) 


Height 
- 
8.72 inches (22.2 cm) 


Depth 
- 
19.00 inches (48.3 cm) 


Weight 
- 
41 pounds 
(21 kg) 


Shipping 
Weight 
(approx.) 
- 
50 pounds 
(25 kg) 


Equipment Supplied 


iSBC®661-1 
- 
Eight-slot 
MULTIBUS 
system 
chassis 


chassis with parallel priority arbitration 
circuitry and 230 
watt linear power supply 


REFERENCE MANUALS (Not included: order separately) 


145340-001 
- 
iSBC 661 System Chassis 
Hardware 


Reference 
Manual 


9800803-03 
- 
iSBC 640 Power Supply 
Hardware 


Reference 
Manual 


144261-002 
- 
iSBC 608/618 
Cardcage 
Hardware 


Reference 
Manual 


Reference manuals may be ordered from any Intel sales 
representative, 
distributor 
office or from Intel Literature 


Department. 


In North America: 
Intel Corp. Literature 
Department 


3065 Bowers Ave. 
Santa Clara, California 
95051 


Phone: (408) 987-8080 


Intel Corp. SA 
Literature 


Department 


Rue du Moulin A Papier 51 
Boite 1 
B-1160 Brussels, 
Belgium 


Phone: 322-661-07-11 


Intel Corp. Literature 
Department 


5-6 Tokodai, 
Toyosato-cho 


Tsukuba-gun, 
Ibaragi-ken 
300-26 


Japan 
Phone: 81-29747-8591 


User Supplied Options 


Compatible 
Rack-Mount 
Slides - 
Chassis Trak, Inc., 


P.O. Box 39100, 
Indianapolis, 
IN 46239; Part No. 
C300S122 


Part Number 
Description 


SBC 6611 
Eight-slot 
MUL TIBUS system 


chassis 
with parallel 
priority 
arbitration 
circuitry 
and 230 wall 
Linear Power Supply 


• Eight-slot cardcage and backplane for 
iSBC computers and expansion 
boards 


• Heavy duty power supply with all 
standard iSBC voltages 


• Compatible with all Intel single board 
computers 


• Forced-air cooling 


• Horizontal board mounting for 
compactness 


The iSBC 660 System Chassis is an attractive, 7-inch high system chassis designed for use with Intel OEM computers. 
It has eight slots for single board computers, memory, I/O,or other expansion modules. The iSBC 660 is ideal for appli- 
cations requiring multiple board solutions. DC power output is provided at + 12V, + 5V, - 12V, and - 5V levels. The 
current capabilities of each of these output levels have been chosen to provide power over a O·C to 50·C temperature 
range for the majority of applications 
requiring combinations 
of computers, memories, peripherals, and other I/O 


capabilities. 
Current limiting 
and over-voltage protection 
is provided at all outputs. Standard logic recognizes a 


system AC power failure and generates a TTL signal for use in power-down control. For user convenience, a reset 
switch is provided on the front panel. The reset signal generated and sent to the system bus can be used for external 
system control. 
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Electrical 
Characteristics 


Input Power 


Frequency: 
50 Hz ± 5%,60 
Hz ± 5% 


Voltage: 
115V 
± 10%, 
230V 
± 10%, 
215 VAC 
± 10%, 


100 VAC ± 10% via user configured 
wiring 
optiong 


Output Power 


Power 
Output Current 
Current 
Limit 
Over-Voltage 
(Ma') 
(Amps) 
Protection 


+ 12V 
4.5A 
5A 
15V ± lV 


+5V 
30A 
3.6 
6.2V 
±OAV 


-5V 
U5A 
2.1 
-6.2V 
±OAV 


-12V 
1.75A 
2.1 
-15V 
± lV 


Combined 
Line/Load Regulation - 
± 1% 
at 
± 10% 
static 
line change 
and ± 50% static 
load change, 
meas- 


ured at the output 
connector 
(± 0.2% 
measured 
at the 
power 
supply 
under the same conditions). 


Remote Sensing - 
Provided 
for 
+ 5 VDC output 
line 


regulation. 


Output Ripple and Noise - 
10 mV peak-to-peak 
maxi- 


mum (DC to 500 kHz). 


Output Transient 
Response - 
Less 
than 
50 /,-s for 


± 50% 
load change. 


Output Transient Deviation - 
Less than ± 5% of linitial 
voltage 
for ± 50% 
load change. 


Power Failure Indication (AC Low) - 
A TTL open collec- 


tor high signal 
is provided 
when the input 
voltage 
drops 


below 90% of its nominal 
value. DC voltages 
will remain 


within 
5% 
of their 
nominal 
values 
for 3.0 milliseconds 


(minimum) 
after 
AC low goes true. 


The "AC 
Low" 
signal 
will 
reset 
to a TIL 
low level when 
the AC input voltage 
is restored 
and after all output 
volt- 
ages are within 
specified 
regulation. 


The 
"AC 
Low" 
threshold 
is 
adjustable 
for 
optimum 


power-down 
performance 
at other 
input 
combinations 
(i.e. 100 VAC, 215 VAC; 50 Hz). 


Humidity - 
Up to 90% relative, non-condensing 
Physical Characteristics 
Height - 
7 in. (17.8 cm) 
Width 
At Front Panel: 19 in. (48.3 cm) 
Behind Front Panel: 17 in. (43.2 cm) 
Depth - 
20 in. (50.8 cm) with all protrusions 


Environmental 
Characteristics 
Temperature 
Operating: O·C to 50·C 
Non-Operating: - 40·C to + 85·C 
Equipment 
Supplied 


iSBC 660 System Chassis with iSBC 640 Power Supply, 
iSBC 6041614CardcagelBackplane, dual fans, pop-off 
front panel 
Connector pack with RS232Ccable (terminal/modem in- 
terface to single board computers). two 50-pin parallel 


I/O connectors for single board computers 
Schematics for cardcagelbackplane, chassis 
Outline drawing 


Reference 
Manuals 


9800505A - 
iSBC 660 Hardware Reference Manual 


(NOT SUPPLIED) 
9800505 - 
iSBC 660 System Chassis Hardware Refer- 


ence Manual (NOT SUPPLIED) 
9800803 - 
iSBC 640 Power Supply Hardware Reference 


Manual (NOT SUPPLIED) 
9800708 - 
iSSC 6041614Cardcage Hardware Reference 


Manual (NOT SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Sowers 
Avenue, Santa Clara, California 95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SSC 660 
System Chassis 


iSBC 640 
POWER SUPPLY 


• 
% 5V and 
% 12V iSBC 80/86 power 


• Sufficient 
power for 8-12 MULTIBUS 
computer, memory, and peripheral 
boards 


• Current limiting and overvoltage 
protection on all outputs 


• "AC low" power failure TIL 
logic level 
output provided for system power-down 
control 


• Compact single chassis/slide 
rail 


mounts in iCS 80 Industrial Chassis or 
OEM environments 


• DC power cables and connectors mate _ 


directly to iSBC 604 Modular Cardcage/ 
Backplane assembly 


• 100, 115, 215, and 230V AC operation 


• 50 Hz or 60 Hz input 


The iSSC 640 Power Supply provides low cost, off-the-shelf, single chassis power generation for OEM and industrial 
system products using Intel single board computers. The iSSC 640 supply provides regulated DC output power at 
+ 12V, + 5V, - 5V and - 12Vlevels. The current capabilities of each of these output levels have been chosen to provide 
power over a O·C to + 55·C temperature range for one fully loaded Intel single board computer, plus residual capability 
for most combinations of up to eleven iSSC memory, 110, or combination expansion boards. Current limiting and over- 
voltage protection is provided on all outputs. Access for AC input is provided via a standard 4-pin keyed connector. DC 
output power levels are provided on cables with keyed connectors directly compatible with the iSSC 604/614 
Modular 


Sackplane/Cardcage assemblies. The iSSC 640 supply includes logic whose purpose is to sense system AC power 
failure and generate a TTL signal for clean system power-down control. 


SPECI FICATIONS 


Electrical 
Characteristics 


Input 
Power 
Frequency: 
50 Hz ± 5%,60 
Hz ± 5% 
Voltage: 
115V ± 10%, 230V ± 10%, 215VAC ± 10%, 


100VAC± 
10% 


Via user configured 
wiring 
options 


Nominal 
Current 
Current 
limit 
Short Circuit 
OV8rvoitage 


Voltage 
(AmpsHMax) 
Range (Amps) 
(AmpsHMax) 
Protection 


+f2v 
4.5A 
4.7- 
6.8 
2.3 
15V ± 1V 
+ 
5V 
30A 
31.5-45.0 
15.0 
6.2V±OAV 


- 
5V 
1.75A 
1.8- 
3.2 
0.9 
- 6.2V ± OAV 
-12V 
1.75A 
1.8- 
3.2 
0.9 
-15V± 
1V 


Combined 
Line/Load 
Regulation 
- 
±1% at ±10% static 
line change and ±50% static load change, 
measured 
at the 
output 
connector 
(±0.2% measured 
at the power 
supply 


under 
the same conditions). 


Remote 
Sensing 
- 
Provided 
for 
+5 VDC 
output 
line 


regulation. 


Output 
Ripple and Noise -10 
mV peak-to-peak 
maximum 


(DC to 500 KHz) 


Output 
Transient 
Response 
- 
Less than 50 !'sec for ±50% 
load change. 


Output 
Transient 
Deviation 
- 
Less than 
± 10% of initial 


voltage 
for 
± 50% 
load change. 


Power 
Failure 
Indication 
(AC 
Low) 
- 
A 
TTL 
open 


collector 
high 
signal 
is provided 
when the input 
voltage 
drops 
below 
90% of its nominal 
value. 
DC voltages 
will 


remain 
within 
5% 
of 
their 
nominal 
values 
for 
3.0 


milliseconds 
(minimum, 
7.5 ms typical) 
after AC Low goes 
true. 


The "AC 
Low" 
signal 
will 
reset to a TTL low level when 


the 
AC 
input 
voltage 
is restored 
and 
after 
all 
output 


voltages 
are within 
specified 
regulation. 


The 
"AC 
Low" 
threshold 
is 
adjustable 
for 
optimum 


powerdown 
performance 
at other 
input 
combinations 


(I.e. 100 VAC, 215 VAC, 50 Hz). 


Mating Connectors1 


AC Input 


03.Q9-2042 or equivalent 


02-09·2118 or equivalent 


(18 to 22 gauge wire) 


Molex 
26-03·3071 
Housing 


Amp 
3-87025·3 


08·50-0187 


Molex 
or 


Pins 
08·50-0189 


Amp 
87023·1 


Moiex 
15-04·9209 
Key 
Amp 
87116·2 


Notes 


1. Pins from given vendor may only be used with connectors 
from the 


same 
vendor. 


2. iSBC 640 DC output 
connectors 
are directly 
compatible 
with input 


power 
connectors 
on 
iSBC 604 
Modular 
Cardcage/Backplane 


assembly. 
Four connectors 
are provided. 


Physical Characteristics 


Height 
- 
6.66 in. max. (16.92 cm) 


Width 
- 
8.19 in. max. (20.80 cm) 


Depth 
- 
12.65 in. max. (32.12 cm) 


Weight 
- 
30 Ibs. max (13.63 kg) 


Environmental 
Characteristics 


Temperature 
- 
O·C to 55·C 
with 
55 CFM moving 
air 


Non·Operating 
- 
- 40·C 
to + 85·C 


Equipment 
Supplied 


iSBC 
640 
Power 
Supply 
with 
AC and 
DC cables 
with 


keyed connectors. 


Reference 
Manuals 


9800803 
- 
iSBC 640 Power Supply 
Hardware 
Reference 


Manual 
(includes 
schematic 
and 
assembly 
drawings) 


(NOT SUPPLIED) 


9800798 
- 
iCS 80 Systems 
Site 
Planning 
and Installa· 


tion 
Manual 
(for installation 
of iSBC 640 supply 
into iCS 


80 Industrial 
Chassis) 
(NOT SUPPLIED) 


Reference 
manuals 
are shipped 
with each product 
only if 


designated 
SUPPLIED 
(see 
above). 
Manuals 
may 
be 


ordered 
from 
any 
Intel 
sales 
representative, 
distributor 


office 
or from 
Intel 
Literature 
Department, 
3065 Bowers 


Avenue, 
Santa Clara, 
California 
95051. 


Part Number 


SBe 640 


Description 


Power Supply 


iSBC 635 
POWER SUPPLY 


• Compact single chassis 


• 
:t 5V and :t 12V iSBC 80 and iSBC 86 
system power 


• Sufficient 
power for one fully loaded 


Intel single board computer plus 
residual power for up to three Intel 
iSBC expansion boards 


• Current limiting and overvoltage 


protection on all outputs 


• DC power cables and connectors mate 


directly to iSBC 604 Modular Cardcagel 
Backplane assembly 


• "AC low" power failure TTL logic level 


output provided for system power- 
down control 


• 100V, 115V, 215V, and 230V AC 


operation 


• 50 Hz or 60 Hz input 


The iSSC 635 Power Supply 
provides 
low cost, off-the-shelf, 
single 
chassis 
power generation 
for OEM products 
using 
Intel 
single 
board 
computers. 
The iSSC 635 supply 
provides 
regulated 
DC output 
power 
at + 12V, + 5V, - 12V, and 
- 12V levels. The current 
capabilities 
of each of these output 
levels have been chosen 
to provide 
power over a O·C to 
+ 55·C 
temperature 
range for one Intel single 
board computer 
fully 
loaded 
with 
I/O line terminators 
and drivers 
and 
EPROMs, 
plus 
residual 
capability 
for most 
combinations 
of up to three 
iSSC memory, 
I/O or combination 
expansion 
boards. 
Current 
limiting 
and overvoltage 
protection 
is provided 
on all outputs. 
Access 
for AC input 
is provided 
via a 


standard 
4-pin keyed connector. 
DC output 
power 
levels are provided 
on cables 
with 
keyed connectors 
directly 
com- 


patible 
with the iSSC 604 Modular 
Cardcage/Sackplane 
assembly. 
The iSSC 635 supply 
includes 
logic 
whose 
purpose 
is to sense 
system 
AC power 
failure 
and generate 
a TIL 
signal 
for clean system 
power-down 
control. 
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SPECI FICATIONS 
Mating Connectors 1 


AC Input 


03-09-1042 or equivalent 


02-Q9-1118 or equivalent 
(18 to 22 gauge 
wire) 


DC Output2 


I 
Header 


Molex 


AMP 


09-66·1071 


87194-6 


Molex 
09-50·7071 
Connector 
AMP 
87159-7 


Molex 
15-04-0219 
Polarizing 
key 
AMP 
87116·2 


Molex 
08-50·0106 (18 to 22 gauge 
wire) 


Pin 
AMP 
87023·1 (18 to 22 gauge 
wire) 


Notes 


1. Pins from a given vendor 
may only be used with 
connectors 
from the 


same vendor. 


2. iSBC 635 DC output 
connectors 
are directly 
compatible 
with power 


input 
power 
connectors 
on 
iSBC 
604 Modular 
Cardcage/Backplane 


assembly. 
Two connectors 
are provided. 


Physical Characteristics 


Height 
- 
3.19 in. max (8.11 cm) 
Width 
- 
6.03 in. max (15.32 cm) 


Depth 
- 
12.65 in. max (32.12 cm) 


Weight 
- 
13 Ib (5.90 kgm) 


Electrical 
Characteristics 


Input 
Power - 
Frequency: 
47 - 63 Hz. Voltage 
(Nominal) 


(Single 
Phase): 
100, 115,215, 
or 230 VAC +10% 


Nomlnel 
Current 
Current 
Limit 
Max Shorl 
Over·Yoltege 


Voltage 
(AMPS)(MAX) 
Range (AMPS) 
Circuit 
(AMPS) 
Protection 


+12 
2.0 
2.1-3.0 
1.0 (Foidback) 
+14to 
+16V 


+ 5 
14.0 
14.7-21.0 
7.0 (Foldback) 
+5.8 to +6.6 V 


- 
5 
0.9 
0.9-1.4 
1.4 
-5.8 to -6.6 V 


-12 
0.8 
0.8-1.2 
1.2 
-14 to -16V 


Combined 
Line/Load 
RegUlation 
- 
±1% at ±10% static 


line change and ±50% static load change, 
measured 
at the 


output 
connector 
(±0.2% measured 
at the power 
supply 


under 
the same conditions). 


Remote 
Sensing 
- 
Provided 
for 
+5VDC 
output 
line 


regulation. 


Output 
Ripple and Noise -10 
mV peak-to-peak 
maximum 


(DC to 500 KHz) 


Output 
Transient 
Response 
- 
Less than 50 Ilsec for ±50% 


load change 


Output 
Transient 
Deviation 
- 
Less than 
±5% 
of initial 


voltage 
for ±50% load change. 


Power Failure 
Indication 
(AC Low) - 
A TIL 
open collec· 


tor high signal 
is provided 
when the input 
voltage 
drops 


below 90% of its nominal 
value. DC voltages 
will remain 


within 
5% 
of their 
nominal 
values 
for 3.0 milliseconds 


(minimum) 
after 
AC low goes true. 


The "AC Low" signal will reset to a TTL low level when 
the AC input voltage is restored and after all output 
voltages are within specified regulation. 


The "AC Low" threshold 
is adjustable for optimum 


powerdown performance at other input combinations 
(i.e. 100 VAC, 215 VAC, 50 Hz). 


Environmental 
Characteristics 


Operating Temperature - 
O·C to + 55·C with 35 CFM 


moving air 


Equipment 
Supplied 


iSBC 635 Power Supply with AC and DCcables and con- 
nectors attached as shown in Figure 1. 


Reference 
Manual 


9800298C 
- 
iSBC 635 Power Supply Hardware Refer- 


ence Manual (includes schematics) (NOT SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California 95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SBC 635 
Power Supply 


intel~ 


iSBC® 608/618 
CARDCAGES 


• Houses eight MULTIBUS@iSBC@ 


boards in an aluminum package 
• Enhanced bus noise immunity for high 


speed systems 


• Board-to-board clearance for iSBC® 


MULTIMODULE™ boards on all slots 
• Plug on iSBC@618 unit for up to 
sixteen board systems 


• Board-to-board clearance for iSBX™ 
MULTIMODULE™ boards on two slots 
• NEMA·type backwall or 19·inch rack 


mount hardware included 


• Parallel priority circuitry for up to eight 
Multimaster iSBC@boards 
• Signal line termination circuitry on 


iSBC@608 Cardcage 


Intel's 
iSBC 608/618 Card cages are matched 
to the latest generation 
of iSBC/iSBX boards which mount in 


the MULTIBUS 
system 
bus. These 
products 
provide 
several 
features 
which 
make them 
the industry's 


leading 
price/performance 
cardcage 
product. 
MULTIMODULE 
board clearance, 
parallel 
priority 
circuitry, 


enhanced 
backplane 
noise immunity, 
and precision 
fit card guides 
are a few of the distinctions 
which 


make this the industry's 
better 
product. 


The iSBC 608 Cardcage is the base unit, housing 
up to eight iSBC boards and their MULTIMODULE 
boards. 


Additionally, 
this base unit provides 
mounting 
hardware and fan mounting 
bracketry. 
The iSBC 618 is the 


expansion 
unit, providing 
eight additional 
iSBC board slots to the iSBC 608 Cardcage for a total of sixteen 


board slots 
which 
can be NEMA·type 
backwall 
or 19-inch rack mounted. 
This is accomplished 
with the 


mounting 
hardware of the iSBC 608 Cardcage. The iSBC 618 expansion 
unit also provides 
fan mounting 


bracketry. 


The 
following 
are trademarks 
01 lntet 
Corporation 
and 
may 
be used 
only 
10 describe 
Inlel 
products: 
Intel, 
CREDIT. 
Index, 
In site, 
Inlallee. 
library 
Manager, 
Megachassis, 


Micromap. 
MULTI BUS, 
PROMPT, 
UPI, ,.Scope, 
Promware, 
MCS, 
ICE. iRMX. 
iSeC, 
iSBX, 
MUlTIMODULE 
and iCS.lntel 
Corporation 
assumes 
no responsibility 
for the use of any 


circuitry 
other 
than circuitry 
embodied 
in an Intel 
product. 
No other 
circuit 
patent 
licenses 
are implied. 


Mechanical Aspects 


The iSBC 608/618 Cardcages 
provide 
housing 
and 


a MUL TIBUS 
system 
bus for up to sixteen 
single 


board computers 
and their 
MULTIMODULE 
boards. 
The iSBC 608 unit and iSBC 618 unit offer 
board-to- 


board clearance 
(0.8 inches 
or greater) 
on all eight 


slots 
for iSBC 
MUL TIMODULE 
boards. 
Two 
slots 


provide 
clearance 
(1.2 inches 
or greater) 
for iSBX 


MULTIMODULE 
boards 
as shown 
in Figure 
1. Each 


cardcage 
includes 
precision 
fitted 
nylon 
card- 


guides 
for 
secure 
board 
fit 
and 
accurate 


MULTIBUS 
board 
pin 
alignment. 
Fan 
mounting 


bracketry 
is 
also 
included 
with 
each 
cardcage. 
This 
bracketry 
allows 
the mounting 
of several 
in- 


dustry 
standard 
fans. The iSBC 608 Cardcage 
base 


unit 
includes 
aluminum 
mounting 
hardware 
for 


NEMA-type 
.backwall 
mounting, 
or anchoring 
a six- 


teen 
slot 
iSBC 608/618 
combination 
in a standard 


19-inch 
rack. 


Electrical Aspects 


The iSBC 608/618 Card cages 
implement 
a parallel 


priority 
resolution 
scheme 
by using 
plug-in 
jumper 
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i5BC' MULTIMODULE'· 
BOA~DSPACING 


connections. 
There 
are 
six 
different 
priority 


schemes 
allowed, 
each 
requiring 
a different 
jumper 
configuration. 
In systems 
where 
an iSBC 


618 Cardcage 
is attached 
to the base unit, the base 


unit will 
have lower 
priority 
overall. 
That is, master 


boards 
in the iSBC 608 base unit may gain control 


of the MULTI BUS lines only when 
no boards 
in the 


iSBC 618 expansion 
unit are asserting 
the bus re- 


quest 
(BREOI) signal. 


Noise-minimizing 
ground 
traces 
are strategically 


interleaved 
between 
signal 
and address 
lines 
on 


these 
backplanes. 
This 
provides 
the 
enhanced 


noise 
immunity 
and 
minimized 
signal-to-signal 


coupling 
which 
is important 
in high 
speed, 
high 


board 
count 
microcomputer 
systems. 


The iSBC 
608/618 
Cardcages 
provide 
power 
con· 


nector 
lug bolts 
for + 5 VDC and ground. 
The lug 


bolts, 
compared 
to other 
power 
connection 
meth- 


ods, 
help 
transfer 
higher 
amounts 
of 
current. 


Other 
voltages 
(± 12 VDC, 
- 10 VDC) 
are 
con· 


nected 
via 
a mating 
power 
connector 
plug 
as 


shown 
in Figure 
2. 
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Bus Lines 


All MULTIBUS 
(IEEE 796) system 
bus address 
and 
command 
lines 
are bussed 
to each of the eight 
MULTIBUS 
connectors 
on the backplane. 
Ground 
traces 
are interleaved 
among 
these 
signal 
lines 
and bussed 
to the backplane 
edge connector 
for 
interconnection 
of 
the 
iSBC 
608 and 
iSBC 
618 
backplane. 


Power Connectors 


Ground 
(OV), + 5V, 
- 5V, + 12V, 
- 12V, 
- 10V 
power 
supply 
header stakes 
and power 
lug bolts 
are provided 
on the iSBC 608/618 
Card cages 
as 
shown 
in Figure 
2. 


Environmental 
Characteristics 


Operating 
Temperature 
- 
O°C to 55°C 


Storage 
Temperature 
- 
- 40°C to 85 °C 


Humidity 
- 
50% to 95% non·condensing 
at 25°C 
to 40°C 


Vibration 
and Shock 
- 
2G max. through 
50 Hz 


Physical 
Characteristics 


SLOT·TO·SLOT 
DIMENSIONS 
(See Figure 
1) 


Top·J1 - 
1.200 in (to center) 


J1·J2 - 
1.300 in (center 
to center) 


J8·BoUom 
- 
0.700 in (to center) 


All Others 
- 
0.800 (center 
to center) 


PHYSICAL 
DIMENSIONS 


Height 
- 
8.38 in (21.29 cm) 


Length 
- 
13.16 in (33.43 cm) 


Width 
- 
7.50 in (19.05 cm) 


Weight 
- 
3.50 Ibs (1.59 kg) 


Shipping 
Weight 
- 
5.75 Ibs (2.61 kg) 


Equipment 
Supplied 


iSBC® 608 BASE UNIT 


Eight·Slots 
- 
Two at greater than 1.2 inches; six at 


0.8 inches 


Male Backplane 
Connector 
- 
For expansion 
with 


iSBC 618 cardcage 


Parallel 
Priority 
Circuitry 
- 
Eight 
slots 
are 


configurable 
via the 
use of 
jumper 
stakes. 
Six 


priority 
schemes 
allowed 


Construction 
Materials 
- 


Aluminum 
card housing 
Nylon card guides 
Power connector 
header stakes 
and lug bolts 


iSBC® 618 EXPANSION 
UNIT 


Eight·Slots 
- 
Two at greater than 1.2 inches; six at 


0.8 inches 


Female Backplane 
Connector 
- 
For expansion 
to 


iSBC 608 base unit 


Parallel 
Priority 
Circuitry 
- 
Eight 
slots 
are 


configurable 
via the 
use 
of jumper 
stakes. 
Six 


priority 
schemes 
allowed 


Construction 
Materials 
- 


Aluminum 
card housing 
Nylon card guides 
Power connector 
header stakes 
and lug bolts 


User·Supplied 
Equipment 


MATING 
POWER CONNECTORS 


Vendor 


3M 
Ansley 
Berg 


Part Number 


3399-6026 
609-2600M 
65485-009 


Vendor 


Rotron 
Torin 
Pamotor 


Part Number 


SU2A 1-028267 
TA300·A30473-10 
8506D 


inter 


144261-001 
- 
iSBC 608/618 
Cardcages 
Hardware 


Reference 
Manual 
(order 
separately) 


Manuals 
may be ordered 
from 
any Intel 
sales 
rep- 


resentative, 
distributor 
office 
or from 
Intel 
Litera- 


tUre Department, 
3065 Bowers 
Avenue, 
Santa Clara, 


California 
95051 


Part Number 


SBC 608 


Description 


Cardcage 
(base unit) 


Cardcage 
(expansion 
unit 
for iSBC 608) 


iSBC 604/614 or (pSBC 604/614*) 
MODULAR 
CARDCAGE/BACKPLANE 


• Interconnection 
on MULTIBUS system 


bus and housing for up to four Intel 
iSBC boards 


• Strong cardcage structure helps 


protect Installed iSBC single board 
computers and expansion boards 
against warping and physical damage 


• Connectors allow Interconnection 
of 


two or more cardcage/backplane 
assemblies 


• Cardcage mounting holes facilitate 


interconnection 
of units 


• Compatible with 3.S·inch RETMA rack 


mount increments 


• Dual backplane power supply 
connectors and signal line termination 
circuits on iSBC 604 Cardcagel 
Backplane 


The iSBC 604 and iSBC 614 Modular Cardcage/Backplane units provide low-cost, off-the-shelf housing for OEM prod- 
ucts using two or more Intel single board computers. Each unit interconnects and houses up to four boards. The base 
unit, the iSBC 604 Cardcage/Backplane, contains a male backplane PCedge connector and bus signal termination cir- 
cuits, plus power supply connectors. It is suitable for applications 
requiring a single unit, or may be interconnected 
with the iSBC 614 Cardcage/Backplane when more then one cardcage/backplane unit is needed. The iSBC 614 Card- 
cage/Backplane contains both male and female backplane connectors, and may be interconnected with iSBC 604/614 
Cardcage/Backplane units. Both units are identical, with the exception of the power connectors and bus signal termi- 
nator features. A single unit may be packaged in a 3.5-inch RETMA rack enclosure, and two interconnected 
units may 


be packaged in a 7-inch enclosure. The units are mountable in any of three planes. 
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SPECIFICATIONS 
Backplane 
Characteristics 


Bus Lines - 
All MULTIBUS system bus address, data, 
and command bus lines are bussed to all four connec- 
tors on the printed circuit backplane 


Power Connectors - 
for ground, + 5V, - 5V. + 12V, 


- 12V, - 10V power supply lines 


iSBC 604 - 
Bus signal terminators, backplane male PC 


edge connector only, and power supply headers 


iSBC 614 - 
Backplane male and female connectors 


Mating Power Connectors 


Connector 
87159·7 


AMP 
Pin 
87023·1 


Polarizing 
key 
87116-2 


Connector 
09·50·7071 


Molex 
Pin 
08-50-0106 


Polarizing 
key 
15-04-0219 


Note 
1. Pins from a given vendor may only be used with connectors 
from the 


same vendor. 


Physical Dimensions 


Height - 
8.5 in. (21.59 cm) 


Width - 
14.2 in. (36.07 cm) 
Depth - 
3.34 in. (8.48 cm) 


Weight - 
35 02 (992.23 gm) 


9800708 
- 
iSBC 604/614 
Cardcage Hardware Reference 


Manual (NOT SUPPLIED) 


Part number 


SBC 604 


Description 


Modular Cardcage/Backplane (Base 
Unit) 


Part Number 


SBC 614 
Description 


Modular Cardcage/Backplane 
(Expansion Unit) 


inter 


iMBX 100/110/120 
MULTIBUS® EXCHANGE 


HARDWARE 
SUBSCRIPTION 
SERVICE 


• Offers 
full update alternatives 
- 
documentation, 
parts kit, and factory 


update 


• Customized 
to the subscriber's 
selec- 


tion of Intel® board level products 
• Timely announcements 
of techno- 


logical 
and product 
developments 


• Ancillary 
Notes clarifying 
and correct· 


ing product 
documentation 
• Available 
for iSBC,TMiCS,TMand iSBX™ 


products 


The Intel MULTIBUS EXCHANGE hardware subscription 
service consists of a monthly update publication 


which provides summary descriptions 
of Engineering Change Orders that alert and inform subscribers of 


all the latest developments and/or improvements applicable to their Intel board level products. In addition, 
the update contains order numbers and prices for optional update parts kits. This timely service allows 
users to closely track product changes and, by evaluating or implementing 
these changes, to take advan- 


tage of technological 
and product developments. 


The following 
ar. 
trademarks 
of Intel 
Corporation 
and may be used only 
to describe 
Intel 
product,: 
Intel, 
CREDIT, 
Index, 
Insite, 
Int_lIee, 
Library 
Manager. 
MegachasslS. 


Micromap, 
MUL TIBUS, 
PROMPT, 
UPI, ~ope, 
Promwar 
•• MeS. 
ICE. iRMX, 
iSBC. 
iSBX, 
MULTIMODULE 
and 
iCS. Inlel 
Corporation 
assumes 
no responsibility 
tor the us. of any 


circuitry 
other than circuitry 
emtxxHed in an Intel product 
No other circuil 
patent Iicen ••• 
ar. 
implied. 


inter 


PRODUCTS 


The MULTIBUS EXCHANGE hardware subscription 
service supports Intelmanufactured Single Board Com- 
puter, Industrial Control Series and MULTIMODULE 
products. Users can subscribe to any combination of 
over 75 products. 


Newsubscribersreceivea historyfor eachsubscribed-to 
product and a handsome notebook in which future up- 
dates may be orderly stored. 


MONTHLY 
UPDATES 


Each month MULTIBUS EXCHANGE subscribers 
receive 
an update 
containing 
summaries 
of 


Engineering 
Change Orders and documentation 


clarification 
articles 
relating to each subscribed- 
to product. Each change description 
includes the 


change 
made, the rationale 
behind the change, 
and the user's alternatives 
concerning 
updating 


his product. Subscribers 
receive the monthly up- 


date even if no changes have occured to their pro- 
ducts. 


Orders for the MULTIBUS EXCHANGE are a com- 
bination of a base (iMBX 100)order, plus orders for 
each product 
to be included 
(iMBX 110s and/or 


iMBX 120s). For each MULTIBUS board, power 
supply, or chassis, an iMBX 110 is ordered. For 
each 
MULTIMODULE 
board, 
an iMBX 
120 is 


ordered. 


For an annual 
subscription 
fee, 
subscribers 


receive twelve monthly updates. All new subscrib- 
ers will also receive a history for each subscribed- 
to product 
at no extra 
charge. 
For additional 


specified 
charges, subscribers 
can purchase the 


associated documentation 
and parts kits listed in 


the MULTIBUS EXCHANGE updates. 


Part Number 
Description 


MBX 100 
Base order for the MULTIBUS 
EXCHANGE hardware 
subscription 
service for one 
year 


MBX 110 
MULTIBUS EXCHANGE 
subscription 
covering one 
MULTIBUS board, power sup- 
ply or chassis for one year 


MBX 120 
MULTIBUS EXCHANGE 
subscription 
covering one 
MULTIMODULE board for one 
year 


Integrated 
2 


Microcomputer Systems 


iSXM™ 
100 
SYSTEM 86/300 SERIES 
X~NIX* SYSTEM EXTENSION 
MODULE 


• Complete 
hardware extension 
to 


execute 
XENIX· 
on Intel® SYSTEM 


86/300 Series microcomputers. 


• Provides memory management 
and 


protection 
to the iAPX 86 processor 


family. 


• Process map cache designed 
to 


provide 
high performance 
context 


switching 
for us~r tasks. 


• Includes 
4 serial connections 
and can 


be expanded 
with additional 
serial 


expansion 
boards. 


• Supported 
by SYSTEM 86/300 Series 


diagnostics 
for ease of repair. 


• Includes 
all necessary 
cables ancl 


mounting 
hardware. 
. 


• Simple integration 
into SYSTEM 


86/300 Series microcomputers. 


The iSXM 100 XENIX System 
Expansion 
Module 
is designed 
to extend 
the hardware capability 
of iSBC 


86/30-based SYSTEM 86/300 Series microcomputers 
in order to execute the multi-user, 
XENIX interactive 


operating 
system. 
This 
field-installed 
module 
provides 
memory 
management 
and memory 
I>rotection 


optimized 
for use with XENIX, four additional 
serial ports, internal 
cables and cable mounting 
hardware. 


All hardware 
is fully configured 
and can be easily 
installed 
in the system. 
An easy-to-follow 
installation 


manual as well as all hardware documentation 
is included 
with the iSXM 100 package. In addition, 
as with 


all hardware 
and peripherals 
in the system, 
the expansion 
module 
is totally 
supported 
by extensive 


diagnostic 
routines. 
These diagnostics 
provide 
a convienent 
and easy to use interface 
for diagnosing 


possible 
problems 
and for r~pid repair. 


• XENIX 
is a trademark 
01 Microsoft 
Corporation. 


The following 
are trademarks 
01 Intel 
Corporation 
and 
may be used 
only 
10 describe 
lnlel 
products: 
Intel, 
CREDIT, 
Indell, 
Insite, 
Intallee, 
Library 
Manager, 
Megachassis, 


Micromap, 
MUL TIBUS, 
PROMPT, 
UPI, IlScope, 
Promware, 
MeS, 
ICE, iAMX, 
iSBC. 
iSBX, 
MULTIMODULE 
and iCS. Intel Corporation 
assumes 
no responsibility 
for the use of any 


circuitry 
other than circuitry 
embodied 
in an Intel product. 
No other circuit 
palent 
licenses 
are implied. 
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The 
iSXM 
100 package 
is composed 
of several 


standard 
modules 
including 
the 
Intel 
iSBC 309 


Memory Management 
MULTIMODULE 
board, iSBC 


534 4·port 
Serial 
Expansion 
board, 
cables 
and 


mounting 
hardware. The addition 
of this kit allows 


the OEM to execute 
the XENIX interactive 
operat· 


ing system 
on Intel boards and systems. 


Memory Manageme.nt 


The 
Intel 
iSBC 
309 
Memory 
Management 


MULTIMODULE 
board is designed 
to add memory 


capability 
to the Intel iSBC 86/30-based processor 


board 
used 
in SYSTEM 86/300 Series 
microcom- 
puters. 
The 
iSBC 309 board, 
which 
operates 
at 


either 5 or 8 MHz; plugs directly 
into the processor 


socket 
of the iSBC 86/30 board and it does not re- 
quire any other 
interface 
or power requirements. 
XENIX takes advantage of these hardware features 
through 
the use of a dynamic 
scatter 
loading tech- 
nique. This method of memory management 
allows 


programs 
to be loaded 
in non-contiguous 
blocks 


of RAM for more efficient 
memory 
utilization. 


The architecture 
of the iSBC 309 Memory Manage- 
ment board is specially 
designed 
to optimize 
the 


performance 
of the XENIX operating 
system. 
On 


the iSBC 309 board there is an eight 
register 
set 


that makes up a process map cache. Through soft- 
ware support 
in the XENIX operating 
system, 
this 


cache contains 
the memory 
locations 
of not only 


the XENIX kernel, but also the seven most recently 
used user processes. 
The Intel implementation 
of 


XENIX, 
using 
a least-used 
process 
algorithm 


(LUP), is constantly 
replacing 
the least used pro- 
cess map with the map of the task that needs to be 
swapped into main memory. This cache of process 
maps allows 
the XENIX operating 
system 
to per- 


form 
context 
switching 
between 
users 
and the 


operating 
system 
much 
faster 
than conventional 


memory 
management 
schemes 
that 
necessitate 


the swapping 
of user maps from a single set of re- 


gisters. 


The iSBC 309 board provides 
two modes 
of 8086 


operation: 
a system (or privileged 
mode) and a user 


mode. 
In the system 
mode the operating 
system 


can map the logical 
address space of a user mode 


process 
anywhere 
in the processor 
one megabyte 


address 
space. The logical 
memory 
is mapped 
in 


2K byte blocks. 
Each block can be marked as non· 


existent, 
read only, or read/write 
memory. 
These 


operations 
are performed 
automatically 
by the 


XENIX operating 
system and are transparent 
to the 


user. 


In the 
user 
mode 
a process 
cannot 
alter 
the 


memory 
map or change 
the process 
number. 
De- 


pending 
on the XENIX configuration, 
up to 7 user 


processes 
(plys 
one system 
process) 
with 
inde- 


pendent 
memory 
maps can be actively 
mapped at 


one 
time. 
The 
ability 
to 
support 
multiple 
pro- 


cesses reduces the operating 
system overhead by 


reducing 
the time spent loading 
the memory 
map. 


The XENIX operating 
system 
available 
from 
Intel 


takes 
full 
advantage 
of these 
powerful 
memory 


management 
features 
available 
on the iSBC 309 


board. For more detailed 
information 
on the iSBC 


309 Memory 
Management 
board refer to the iSBC 


309 
Memory 
Management 
board 
data 
sheet, 


number 
210496-001. 


Serial I/O Expansion 


In addition 
to the one serial 
I/O channel 
resident 


on the iSBC 86/30 processor 
board, the iSXM 100 


package 
provides 
four 
additional 
ports 
through 


the use of an Intel 534 Serial Expansion 
board. 


The iSBC 534 board 
is shipped 
fully 
configured 


and ready to install 
in the SYSTEM 86/300 Series 


microcomputer. 
The board 
interfaces 
directly 
to 


the system 
through 
the industry 
standard 
(IEEE- 


P796) MUL T1BUS system bus. The four serial ports 
fully 
support 
RS232C (configured) 
asynchronous 


communications. 


The XENIX operating 
system 
available 
from 
Intel 


has complete 
support 
for Bell 103 (300 baud) and 


Bell 212 (300 or 1200 baud) compatible 
modems 
in 


both answer and originate 
mode. When in a local 


environment, 
asxnchronous 
data rates up to 9600 


baud are supported. 


Additional 
iSBC 534 boards may be added by the 


user to expand 
beyond 
the 4 additional 
serial 
I/O 


ports supplied 
with the iSXM 100 package. 


MOUNTING 
HARDWARE AND CABLES 


Four RS232C cables 
for use from 
the edge con- 


nectors 
of the iSBC 534 board to the back of the 


SYSTEM 86/300 Series chassis 
are included 
in the 


iSXM 100 package. 
An expansion 
cable mounting 


bracket 
is also supplied. 
This bracket 
mounts 
on 


the back of the system 
chassis 
allowing 
for the 


connection 
of up to eight RS232C·type cinch con· 


nectors. 


DIAGNOSTICS 


When 
the 
Extension 
Module 
is used 
with 
Intel 


SYSTEM 86/300 Series 
microcomputer 
systems, 


there 
is a two level diagnostic 
program 
that sup· 


ports 
both 
the 
iSBC 
309 Memory 
Management 


board 
and 
the 
iSBC 
534 
Serial 
I/O 
Expansion 


board. The first 
level of diagnostics, 
the System 


Confidence 
Test (SCT) is based in EPROM on the 


iSBC 
86/30 
processor 
board. 
This 
test 
gives 
a 


go/no·go 
condition 
on all 
hardware 
and 
periph- 


erals present 
in the system. 
If a no-go condition 


exists, 
then the second 
level of diagnostics 
may 


be executed. 
The disk-based 
Systems 
Diagnostic 


Test (SOT) runs detailed 
diagnostics 
on specific 


pieces 
of hardware 
such as the memory 
boards, 
processor 
or memory 
management 
unit. 


INSTALLATION 


The iSXM 100 XENIX System 
Extension 
Module 
is 


desig'1ed 
to 
be 
field 
installed 
into 
any 
iSBC 


86/30·based 
SYSTEM 
86/300 
Series 
microcom· 


puter. An installation 
guide giving detailed 
instruc· 


tions is included 
with the iSXM 100 package. Total 


installation 
time for the hardware 
kit is estimated 


to be less than one hour. Complete 
hardware 
in- 


stallation 
can also be provided 
by Intel Field Servo 


ice Engineers 
for an optional 
fee. Contact 
the local 


Intel 
Sales 
Office 
or 
Intel 
distributor 
for 
more 


information 
on field service 
installation. 


Hardware Supplied 


iSBC 309 Memory 
Management 
board 


iSBC 534 4-port Serial I/O Expansion 
board 


Four card edge to RS232C serial cables 
Serial cable mounting 
bracket 


Electrical 
Requirements 


Current 
Draw (Max) 


Voltage 
- 
iSBC 309 
iSBC 534 


+ 
5 
2A 
1.9 A 


+ 12 
420 mA 


-12 
400 mA 


Environmental 
Characteristics 


OPERATING TEMPERATURE 


ISXMTIO100 - 
0° to 55°C 


SYSTEM 86/300 Series Microcomputers 
- 


15° to 35°C 


Communication 
Capabilities 


Hardware 
- 
iSBC 534 4-port Serial I/O Expansion 


board 


Interface 
Support 
- 
RS232C 


Modem Support 
- 
300 baud - 
Bell103A 
or equiv- 


alent; 300 baud, 1200 baud - 
Bell 212A or equiva· 


lent 


Physical 
Characteristics 


iSBC 309 
iSBC 534 


Width 
- 
6.00 in (15.24 cm) 
12.00 in (30.48 cm) 


Length 
- 
5.75 in (14.61 cm) 
6.75 in (17.15 cm) 


Height 
- 
1.14 in (2.90 cm) 
.50 in (1.27 cm) 


iSXM™ 100 Shipping 
Weight 
- 
10 pounds 


Reference 
Manuals 


144686-001 
iSBC 309 User's Guide 
9800450-02 
iSBC 534 Hardware Reference Manual 


144778-001 
iSXM 100 XENIX Installation 
Guide 


ORDERING INFORMATION 


The iSXM 
100 XENIX 
System 
Extension 
Module 


may 
be 
ordered 
separately 
as 
the 
iSXM 
100 


module 
or 
as part 
of 
the 
SYSTEM 
86/300X 
or 


86/380X kit. 


The XENIX software 
package 
may also be ordered 


separately 
from Intel as SD12XNX86H 


inter 


SYSTEM 86/380X 
MICROCOMPUTER 
SYSTEM 
XENIX· 


• Industry 
standard 
XENIX interactive 


operating 
system 


• Memory management 
and protection 


for the high·performance 
8 MHz 16·bit 


iAPX 86110 processor 


• Standard 
language 
support 
includes 


"C" 
and ASSEMBLER·86. 
Other 


languages 
available 
soon 


• Expansion 
provided 
for ten 


MUL TIBUS@iSBC@boards and one 
8·inch standard 
peripheral 
in two desk· 


top or rack·mount 
chassis 


• Meets the open system 
requirements 


of the OEM 


• 35MB Winchester 
and 1MB diskette 


drive for program, 
data storage, 
and 


back·up 


• 384KB of high speed RAM memory 
for 


multiple 
users and processes 


• Extensive 
self·test 
routines 
to ensure 


reliable 
operation 
and enhance 
fault 


isolation 


• Five serial ports included 
(expandable 


to nine ports) 


The Intel SYSTEM 
86/380X 
Microcomputer 
System 
is an integrated, 
high-performance 
16-bit XENIX-based 
hardware/software 
package 
designed 
for the OEM, yielding 
all the benefits 
of the latest 
advances 
in VLSI 
technology 
and performance 
without 
requiring 
complex 
system 
integration. 
The system, 
based 
on stand- 
ard Intel 
MULTIBUS 
board and chassis 
products, 
comes 
complete 
with connections 
to five user terminals 
(expandable 
to nine), a state-of-the-art 
35MB Winchester 
disk, and a 1MB diskette 
drive. 
In addition 
to the 
standard 
OEM XENIX 
multi-user 
operating 
system, 
SYSTEM 
86/380X is also supplied 
with an efficient 
"C" 


compiler, 
editor, 
debugger 
and all other 
standard 
XENIX 
software. 
Substantial 
expansion 
capacity 
is pro- 


vided 
for both 
MUL TIBUS 
boards 
and an additional 
8-inch 
standard 
peripheral, 
allowing 
large computing 
systems 
to be built 
quickly 
to take advantage 
of rapidly-changing 
OEM opportunities. 


""",,",,,,"""' 
a:r 


• XENIX is a trademark 
of Microsoll 
Corporation. 


The fOllowing 
are trademarks 
01 Intel 
Corporation 
and may be used 
only 
10 describe 
Intel 
products: 
Intel, 
CREDIT, 
Index, 
Insile, 
Intellee, 
library 
Manager. 
Megachassis. 


Micromap, 
MUl TIBUS, 
PROMPT, 
UPI, ",SCope, 
Promware. 
MeS, ICE. iRMX. 
iSeC, iS8X, 
iSXM, 
MULTICHANNEL, 
MUL TIMODULE 
and iCS. Intel Corporation 
assumes 
no responsi· 


bility 
for the use 01 any circuitry 
other 
than circuitry 
embodied 
in an Inlel 
product. 
No other 
circuit 
patent 
licenses 
are implied. 


inter 


The SYSTEM 86/380X 
is a complete 16-bit micro- 


computer system designed to execute UNIX!, the 
standard interactive multi-user operating system. 
The SYSTEM 86/380X operates under the control 
of XENIX, a fully-licensed 
implementation 
of Bell 


Laboratories 
UNIX V7 that has been designed 


specifically 
to execute on the high-performance 


iAPX 86/10 16-bit processor. The system's 
hard- 


ware is based on the Intel SYSTEM 86/380, plus the 
addition of the iSXM 100XENIX System Extension 
Module, 
which 
includes 
four additional 
serial 


channels (expandable to nine), processor memory 
management and protection hardware, cables and 
mounting 
hardware. 
The addition 
of the Intel- 


supplied XENIX software and the Extension Mod- 
ule expand the capability of the system to execute 
this interactive, multi-user operating system. 


PRINTER 


INTERFACE 
(50·PIN PARALLEL 
I/O) 


USER TERMINAL 


INTERFACE 
(RS232) 


ISBC" 86130 
SINGLE 
BOARD 
COMPUTER 


• 
IAPX 86110 PROCESSOR 


• 
128K BYTES RAM 


• 
32K BYTES PROM 


• 
ISBC" 309 MEMORY 
MANAGEMENT 
MODULE 


ISBC-215 
WINCHESTER 
DISK 
CONTROLLER 


Designed for OEM Open Systems 
Market Requirement 


The SYSTEM 86/300 
family 
of microcomputer 


systems are designed to meet the emerging OEM 
systems market requirement for "open" systems. 
Open-systems requirements demand that the sys- 
tem be (1)open to easily absorb the next two gen- 
erations of VLSI microcomputers, 
(2) open to in- 


stantly 
leverage off industry 
standard hardware 


modules and interfaces (such as the MULTIBUS 
and iSBX buses), (3) open to easily tap industry 
standard software from Intel and independent ven- 
dors, (4) open to industry standard data communi- 
cation interconnections, 
and (5) open to allow the 


OEM to participate 
at any level of integration: 


systems, 
boards 
and components. 
The open 


SYSTEM 86/300 
microcomputer 
family 
provides 


the OEM with instant access to VLSI technology, 
the instant leverage and stability of software and 
hardware standards and documentation; 
and the 


only design 
approach 
to keep pace with 
VLSI 


technology. 


ISBC"056A 
MEMORY 
EXPANSION 
256K BYTES 
DYNAMIC 
RAM 


ISBC" 534 
COMMUNICATIONS 
EXPANSION 
FOUR RS232 PORTS 


inter 


Central 
Processor 
- 
The controlling 
element 
of 
SYSTEM 86/380X is the iSBC 86/30 Single 
Board 
Computer. 
The central processor 
of the iSBC 86/30 
Single Board Computer 
is the powerful 
16·bit 8086, 
operating 
at 8 MHz. The architecture 
of this VLSI 
processor 
includes 
four 
16-bit 
byte-addressable 
registers 
and two 
16-bit index 
registers, 
accessi- 
ble by a total of 24 operand addressing 
modes for 
complex 
data 
handling 
and flexible 
memory 
ad· 
dressing. 


Memory 
- 
Resident 
on the iSBC 86/30 board are 
128KB of high-performance 
dual·ported 
RAM ac- 
cessible 
to both the local and MULTIBUS system. 


Expansion 
- 
The iSBC 86/30 board also supports 
one connector 
for the iSBX bus, an expansion 
bus 
allowing 
the 
user 
to 
add 
parallel 
or serial 
I/O, 
analog 
I/O, peripheral 
controllers, 
and other func- 
tions at low cost without 
requiring 
the use of addi- 


tional 
MULTIBUS 
board slots. 


Other Facilities 
- 
The processor 
board includes 
an RS232C serial channel 
for communication 
with 
a user-supplied 
terminal 
through 
a connector 
at 
the back of the chassis; 
asynchronous 
baud rates 
of 110 to 9.6K are available 
on this 
port. A 50-pin 
parallel 
I/O interface 
cabled 
to the 
back of the 
chassis 
supports 
signal 
levels 
of 
the 
industry· 
standard 
Centronics 
printer 
interface. 


MEMORY EXPANSION 


In addition 
to the 128KB of RAM on the processor 
board, the SYSTEM 86/380X also includes 
a 256KB 
memory 
expansion 
board. This brings the system 
RAM 
memory 
supplied 
with 
the 
base 
SYSTEM 
86/380X to 384KB. The memory 
devices 
used are 
the 
latest·technology 
64K-bit 
dynamic 
RAMs. 
Through 
the use of optional 
memory 
expansion 
boards, the total capacity 
of the SYSTEM 86/380X 
may be expanded 
to one megabyte; 
as an example 
of the capabilities 
inherent 
in the open architec· 
ture of Intel systems, 
128K bytes of this expansion 
could 
be implemented 
with the iSBC 304 Memory 
Expansion 
MULTIMODULE, 
which 
increases 
the 
overall system 
performance 
by placing 
even more 
memory 
on the single 
board computer 
and reduc· 


ing MULTIBUS data and instruction 
traffic. 


MASS STORAGE 


Winchester 
Disk 
Drive 
- 
The SYSTEM 86/380X 
contains 
a high 
performance 
35MB 
(32MB 
for- 


matted) 
8-inch Winchester 
fixed-media 
disk drive 


for program 
and data 
storage. 
The drive 
has an 


average 
access 
time 
of 43 milliseconds 
and 
a 


transfer 
rate of 6.44 Mbits/sec. 


Diskette 
Drive - 
An 8-inch double-density/double- 


sided 
diskette 
drive with 
1M byte capacity 
is in- 


cluded in the base system. This high·density 
drive, 


which 
has an average ,access time of 91 millisec- 


onds and a transfer 
rate of 500Kbits/sec, 
can be 


used for both data storage and system 
backup. 


Intelligent 
Controller 
- 
The 
SYSTEM 
86/380X 


uses 
the 
intelligent, 
8089-based 
iSBC 
215 Win- 


chester 
Disk Controller. 
This high performance 
in- 


terface 
contains 
firmware 
which 
is executed 
directly 
on the 8089 I/O processor. 
This 
I/O pro- 


cessor, 
coupled 
with an onboard 
RAM buffer, 
off- 
loads 
a significant 
portion 
of disk 
I/O overhead 


from the host 8086 processor. 


Diskette 
Controller 
- 
In addition 
to 
the 
Win- 


chester 
control 
firmware, 
there is also 8089 firm- 


ware resident on the iSBC 215 board to control 
the 


iSBX 218 Flexible 
Disk Controller. 
This controller 


plugs directly 
onto the iSBC 215 board via one of 


the two available 
iSBX connectors. 


Mass storage 
expansion 
beyond 
the single 
Win- 
chester and floppy diskette 
drives configured 
with 


the system 
is easily 
accomplished 
by the OEM 


through 
the use of unused connectors 
at the ends 


of the daisy-chained 
cables already installed 
in the 


peripheral 
package. 
There 
is sufficient 
cable 


length 
remaining 
to connect 
either 
an additional 


(compatible) 
diskette 
or Winchester 
drive, at the 


customer's 
choice, 
to 
be installed 
in the 
open 


position 
of the peripheral 
chassis. 
In addition 
to 


the Winchester 
and diskette 
interfaces 
provided 


with the system, Intel also can provide a MULTIBUS 
controller 
board and iRMX 86 software 
for SMD- 


compatible 
disk drives. 


iSXM™ 100 XENIX System 
Extension 
Module 


The iSXM 100 XENIX System 
Extension 
Module 
is 


composed 
of two user·installed 
boards 
including 


the Intel iSBC 309 Memory 
Management 
and Pro· 


tection 
MULTIMODULE 
board 
and the 
iSBC 534 


Four Channel 
Communications 
Expansion 
board; 


cables and mounting 
hardware for the terminalI/O 


ports 
are also 
included. 
The addition 
of this 
kit 


allows 
the OEM to execute 
the XENIX interactive 


operating 
system. 


MEMORY 
MANAGEMENT 
AND PROTECTION 


The 
Intel 
iSSC 
309 
board 
is designed 
to 
add 


memory 
management 
capability 
to the SYSTEM 


86/380X 
microcomputers. 
The 
iSSC 
309 
board 


plugs 
directly 
into 
the 
processor 
socket 
of the 


iSSC 86/30 board, and it does not require any addi- 
tional 
interface 
or power requirements. 


The architecture 
of the iSSC 309 board is specially 


designed 
to 
optimize 
the 
performance 
of 
the 


XENIX operating 
system. 
There 
is a set of eight 


registers 
on the iSSC 309 board that 
make up a 


system 
process 
map 
cache. 
Through 
software 


support 
in the XENIX operating 
system, this cache 


contains 
the 
memory 
locations 
of 
not 
only 
the 


XENIX 
kernel, 
but also 
the seven 
most-recently- 
used user processes. 
The Intel implementation 
of 


XENIX constantly 
replaces 
the map of the least- 


used process with the map of the process about to 
become 
active. 
This 
cache 
of 
process 
map ad- 
dresses allows 
the XEN IX operating 
system to per- 
form 
context 
switching 
between 
users 
and the 


operating 
system 
much 
faster 
than conventional 


memory 
management 
schemes 
that 
necessitate 


the swapping 
of user addresses 
through 
a single 


set of registers. 


The iSSC 309 board provides 
two modes 
of 8086 


operation: 
a system (or privileged) 
mode and a user 
mode. 
In the system 
mode the operating 
system 


can map the logical 
address 
space of a user mode 


process 
anywhere 
in the processor's 
one mega- 
byte address space. The logical memory is mapped 
in 2K byte blocks. 
Each block 
can be marked 
as 


non-existent, 
read 
only, 
or 
read/write 
memory. 


These operations 
are performed 
automatically 
by 


the XENIX operating 
system and are transparent 
to 


the user. 


In the 
user 
mode 
a process 
cannot 
alter 
the 


memory 
map or change 
the process 
number. 
De- 


pending 
on the XENIX configuration, 
up to 7 user 


processes 
(plus 
one system 
process) 
with 
inde- 
pendent 
memory 
maps 
can 
be mapped 
at one 


time. The ability 
to support 
multiple 
process 
maps 


reduces 
the operating 
system 
overhead 
by reduc- 
ing the time spent 
loading 
the memory 
map. 


The XENIX operating 
system 
available 
from 
Intel 
takes 
full 
advantage 
of these 
powerful 
memory 


management 
features 
available 
on the iSSC 309 


board. For more detailed 
information 
on the iSSC 


309 board refer to the iSSC 308/309 Memory 
Man- 
agement 
and 
Protection 
MULTIMODULE 
boards 


data sheet, number 
210496-001. 


Serial I/O Expansion 


In addition 
to the one serial 
I/O channel 
resident 


on the iSSC 86/30 processor 
board, the iSXM 100 


module 
provides 
four additional 
ports through 
the 


use of an Intel iSSC 534 Serial 
Expansion 
board. 


T~ese ports are easily connected 
to any standard 


RS232C terminal. 
When 
in a local 
environment, 


asynchronous 
data rates up to 9.6K baud are sup- 


ported. 


The iSSC 534 board 
is shipped 
fully 
configured 


and ready to plug in the SYSTEM 86/380X system. 
The board interfaces 
pirectly 
to the system through 


the 
industry-standard 
(IEEE-796) 
MULTISUS 


system 
bus. Additional 
iSSC 534 boards 
may be 


added 
by the user to expand 
beyond 
the 4 addi- 


tional 
serial 
I/O ports supplied 
with 
the iSXM 100 


package. 


INSTALLATION 


The iSXM 100 module 
is designed 
to be field 
in- 


stalled 
into any iSSC 86/30-based 
SYSTEM 86/380 


microcomputer. 
An iSXM 
100 Installation 
Guide 


giving 
detailed 
instructions 
is includ.ed 
with 
the 


iSXM 100 Kit. Total 
installation 
time for the hard- 


ware kit 
is estimated 
to be less 
than 
one 
hour. 


Complete 
hardware 
installation 
can also 
be pro- 


vided 
by Intel 
Field 
Service 
Engineers 
for an op- 


tional 
fee. Contact 
the local 
Intel Sales Office 
or 


Intel distributor 
for more information 
on field serv- 


ice installation. 


System Chassis 


SYSTEM 
PACKAGING 
CONFIGURATION 


The SYSTEM 86/380 is packaged 
in two chassis. 


Module Package - 
This package contains 
a 14-slot 


cardcage, 
all of whose 
slots 
accept 
MULTISUS- 


compatible 
boards with 
iSSC MULTIMODULE 
ex- 


pansion boards attached 
(See Figure 1). In addition, 


three of the slots are sufficiently 
far from adjacent 


slots 
to allow 
boards 
with 
iSSX MUL T1MODULE 


boards 
to be inserted, 
with 
no penalty 
in loss of 


slots. 
Two of these 
wide 
slots 
and two standard 


slots are utilized 
by the boards which 
make up the 


SYSTEM 86/380X, leaving ten slots (one wide, nine 
narrow) for user expansion. 
I/O cables run from the 


boards 
in the Module 
Package 
to connectors 
on 


the back of the package; 
interconnecting 
cables 


run from 
that point 
to the back of the Peripheral 


Package. 


inter 


Figure 1. Interior 
of SYSTEM 86/380X 
Module 
Package 


Peripheral 
Package 
- 
This 
package 
houses 
the 


Winchester 
and diskette 
drives (see Figure 2). One 
position, 
suitable 
for mounting 
any industry-stand- 
ard 8-inch peripheral 
drive, is available to the user. 


•.... 


Figure 2. Interior 
of SYSTEM 86/380X 
Peripheral 
Package 


The two 
chassis 
may be used on a desk top or 
mounted 
(with 
user-supplied 
slides) 
in a user- 


furnished 
19-inch 
EIA equipment 
rack. The two 
packages 
are connected 
with 
a set of cables 
ap- 
proximately 
4.5 feet long. Knock-outs 
are available 
on the back 
panel 
of each chassis 
to allow 
the 
OEM to easily configure 
additional 
1/0 connectors 


into 
the 
system 
(see 
Figure 
3). The 
SYSTEM 


86/380X 
has been designed 
to meet UL and CSA 
safety and FCC EMI/RFI requirements. 


GENERAL 
DESCRIPTION 


The SYSTEM 86/380X 
executes 
the industry 
stand- 


ard, interactive 
operating 
system, XENIX. XENIX is 
a fully-licensed 
Intel 8086 adaptation 
of the Bell 
Laboratories 
Version 
7 UNIX operating 
system. 


The 
XENIX 
system 
is an 
interactive, 
protected 


multi-user, 
multitasking 
operating 
system 
with 
a 
powerful, 
flexible 
human interface. 
The operating 
system 
is well 
suited 
to applications 
requiring 


multiple 
persons 
running 
independent, 
terminal- 


oriented 
jobs. 
Example 
applications 
include 
dis- 


tributed 
data processing, 
business 
data process- 


ing, 
software 
development 
and 
engineering 
or 


scientific 
data analysis. 


The differences 
between 
XENIX and UNIX V7 can 


either be classified 
as improvements 
or enhance- 


ments 
over 
the 
standard 
Bell 
Laboratories 
pro- 


duct. 


Improvements 
are 
changes 
that 
are 
made 
to 
enhance 
reliability 
and performance 
of the operat- 


ing system 
but are transparent 
to the 
user. 
En- 


hancements 
are new 
features 
to 
the 
operating 
system which applications 
software 
programmers 


can take advantage 
of. 


The major improvements 
and enhancements 
that 


are available 
in Intel's version of the XENIX operat- 


ing system 
running on the SYSTEM 86/380X 
micro- 
computer 
are as follows: 


Automatic 
Disk 
Recovery 
- 
XENIX writes 
infor- 
mation 
on the disk 
in a more structured 
manner. 


Unlike UNIX, XENIX is able to recover information 
on the disk in the event of a system 
crash (unless 


there is a media failure). A special 
program, FSCK, 
cleans and restructures 
an unhealthy 
disk. 


Size and Speed 
- 
The implementation 
of XENIX 


used in the SYSTEM 86/380X 
has been optimized 


for both the 8086 microprocessor 
and for use on 


the hardware offered 
on the Intel system. Specific 


improvements 
have been made in such areas as 


memory 
management, 
serial 
I/O drivers 
and disk 


drivers to name a few. 


Floating Point - 
Floating point routines are moved 


from 
each 
individual 
program 
to a single 
copy 


located 
in the kernel. 
This 
saves memory 
space 


and improves 
system 
performance. 


System 
Configuration 
- 
To 
make 
it 
easier 
to 


generate a new XENIX system there is a new inter- 
active 
configuration 
utility 
supplied 
with 
the 


system to allow the user to specify 
device drivers, 
disk buffers, 
memory 
size etc. For more informa- 
tion on other enhancements 
and improvements 
to 


the XENIX operating 
system 
please 
refer to the 


Intel XENIX data sheet. 


Scatter 
Loading 
- 
In conjunction 
with 
the iSSC 


309 
Memory 
Management 
board 
used 
in 
the 


SYSTEM 86/380X 
a sophisticated 
memory 
alloca- 


tion algorithm 
is used to maximize 
memory utiliza- 
tion 
and 
minimize 
system 
swapping. 
The eight 


register 
sets that make up the process 
map cache 


on the iSSC 309 are constantly 
replacing 
the least 


used process 
address 
with 
the address 
of a pro- 
cess that is currently 
swapped 
out and wants 
to 


execute. 
Unlike 
most 
minicomputer 
implementa- 


tions of UNIX, which need large contiguous 
blocks 


of memory, XENIX running on the SYSTEM 86/380X 
can load multiple 
2K-byte blocks 
of a user's 
pro- 


gram in non-contiguous 
memory. 
This allows 
the 


operating 
system 
to 
utilize 
memory 
more 
effi- 


ciently 
and 
significantly 
reduces 
memory 
frag- 


mentation 
and system 
swa"pping "for higher 
per- 
formance. 


The 
XENIX 
operating 
system 
programs 
can 
be 


described 
as being in three major categories: 


Kernel 
- 
The kernel 
manages 
data storage 
and 


schedules 
tasks and manages 
main memory 
and 


peripherals. 


Shell - 
This program 
is the human interface 
that 


interprets 
the 
commands 
typed 
by a user. 
The 


shell calls 
in user programs 
from storage 
and ex- 


ecutes 
them one at a time or in a series called 
a 


"pipe". 


Utility 
Programs 
- 
These 
programs 
perform 
a 


number 
of system 
routines 
such 
as compiling, 


editing, 
file maintenance, 
etc. 


XENIX 
OPERATING 
SYSTEM 
FEATURES 


Device independent 
1/0 - 
Application 
software 
is 


written 
with 
device 
independent 
I/O. This allows 


the 
user 
to define 
the 
peripheral 
device 
at run 


time. 


Tree-structured 
File 
Directory 
and 
Task 
Hierar- 


chies 
- 
Users can access 
information 
on secon- 


dary 
storage 
by referring 
to file 
with 
its 
ASCII 


name. The names of files 
stored 
on a device 
are 


stored 
in special 
files called directories. 
As direc- 


tories 
are themselves 
named files, the XENIX file 


system allows 
directories 
to contain 
the names of 


other 
directories. 
This 
structure 
is 
useful 
for 


isolating 
collections 
of file to an application, 
and 


for tailoring 
system 
data to the requirements 
of 


users and applications 
sharing 
storage 
devices. 


Re-entrantiShared 
Code 
- 
The 
XENIX 
system 


automatically 
separates 
code 
and 
data. 
This 


allows both systems 
programs 
such as editors 
and 


compilers 
as well as user code to be both shared 


and re-entrant. 
This method 
of memory allocation 


results 
in a more efficient 
memory 
utilization 
and 


higher performance 
system. 


System 
Accounting 
and Security 
Access 
Protec- 


tion - 
The XENIX system has a complete 
security 


system 
for both system 
and file access. 
All data 


concerning 
system usage is also available for user 


accounting 
programs 
and system 
tuning. 


In addition 
to 
the 
operating 
system 
itself, 
the 


XENIX system includes 
all of the support 
software 


developed 
by 
Sell 
Laboratories 
that 
has 
been 


added to the UNIX system during 
the last decade. 


It includes: 


• 
Microsoft 
implementation 
of the Ritchie 
and 


Kernighen 
C compiler 


• Text editing 
and typesetting 
software 


• Subroutine 
libraries 


• Assembler 
and debugger 


• System 
software 
development 
tools 


COMPREHENSIVE 
SELF·TEST 
AND SYSTEM 
DIAGNOSTICS 


In order 
to ensure 
correct 
system 
operation 
and 
assist 
in rapid location 
of both hardware 
and soft- 
ware problems, 
the SYSTEM 86/380X 
is supplied 


with two levels of diagnostic 
routines: 


SCT (System 
Confidence 
Test) 
- 
Automatically 
executed 
at power on and system 
reset, the SCT 


performs 
a GO-NO GO condition 
for the proces- 


sors, memory 
and devices 
in the system. 


SOT (System 
Diagnostic 
Test) - 
In the event that 
the SCT finds 
a system 
problem, 
the SOT may be 
executed 
by the user for a detailed 
analysis 
of the 
hardware 
status. 
This easy-to-use 
monitor-based 
program can perform 
tests on all hardware 
boards 
and mass storage 
peripherals 
in the system. 


Word Size 


GENERAL PURPOSE PROCESSOR 


Instruction 
- 
8, 16, or 32 bits 


Data - 
8/16 bits 


Instruction Cycle Time 


250 nanoseconds 
for fastest executable 
instructions 


(assuming 
8 MHz clock 
rate and the instruction 
is 


in the queue). 


750 nanoseconds 
for fastest 
executable 
instructions 


(assuming 
8 MHz clock 
rate and the instruction 
is 


not in the queue). 


Memory Capacity 


RAM - 
384K bytes supplied 
with the base system. 
Memory 
may be expanded 
to 1 megabyte. 


Interface 


EIA Standard 
RS232C 
signals 
provided 
and 
sup- 
ported. 


Serial - 
Five RS232C ports configurable 
from 
110 


to 9.6K baud asynchronous 


Parallel 
- 
A 50-pin 
parallel 
I/O port 
that 
is sup- 


plied 
with 
signal 
levels 
compatible 
with 
the 
in· 


dustry 
standard 
Centronics 
printer 
interface 
(OEM 


supplied 
cable) 


AC Requirements 


Module 
Package 
- 
1738W 
maximum 
power 
con- 


sumption; 
12.5A 
@ 92-126 
VAC, 
60 
Hz single- 


phase (US); 6.3A @ 184-252 VAC, 50 Hz (Eur); 13.8 A 
@ 92·126 VAC, 50 Hz single-phase 
(Japan) 


Peripheral 
Package 
- 
693W maximum 
power con- 


sumption; 
5.0A 
@ 92-126 VAC, 60 Hz single-phase 


(US); 2.5A 
@ 
184-252 
VAC, 
50 Hz (Eur); 
5.5A 
@ 


92·126 VAC, 50 Hz single·phase 
(Japan) 


Product Safety Standards 


The system 
is designed 
to meet 
UL standard 
114 


Safety 
of 
Electronic 
Data 
Processing 
Units 
and 


Systems, 
plus 
the 
Canadian 
Standards 
Associa· 


tion 
standard 
C22.2 
154-1975 Safety 
of Data 
Pro· 


cessing 
Equipment. 
The system 
is also 
designed 


to 
meet 
the 
applicable 
RFI/EMI 
requirements 
of 


VDE 0871/6.78, 
VDE 0875/6.77 and FCC rule 47 CFR 


part 
15 subpart 
J Emission 
Limits 
for Computing 


Devices. 


Environmental Requirements 


OPERATING 


Temperature 
- 
15·C to 35·C 


Relative Humidity 
- 
20% to 80% 
non·condensing 


over the operating 
temperature 
range' 


Vibration 
- 
0.01g inches 
peak·to·peak, 
5 - 25 Hz; 


0.2g O-to-peak, 25·65 
Hz; 0.3g O-to·peak, 65 - 300 Hz 


°NOTE: The environmental combination of humidity and tern· 


perature together cannot exceed 26·C wet bulb. 


NON·OPERATING 


Temperature 
- 
- 25·C 
to 60·C 


Relative Humidity 
- 
20% to 80% 
non·condensing 


Vibration 
- 
.020 inches, 
peak-to-peak, 
5 . 25 Hz; 


.010 inches, 
peak·to-peak, 
25 . 65 Hz; 2.0g, 
O-to- 


peak, 65 - 300 Hz 
. 


Physical Characteristics 


Both 
the 
Module 
Package 
and 
the 
Peripheral 


Package 
have the same dimensions. 


Width 
- 
16.8 in. (42.6 em) 


Height 
- 
12.2 in. (31.1 em) 


Depth - 
23.0 in. (58.4 em) 


Weight 
- 
Module 
Package 
- 
55 
Ib 
(25 
kg); 


Peripheral 
Package 
- 70 Ib (32 kg) 


In addition 
to these 
two 
Packages, 
the chassis 
in- 


terconnecting 
cables 
weigh 
approximately 
5 Ib (3 


kg). 


Part Number 


SYS86380ABX 
KIT 


SYS86380ACX 
KIT 


Description 


(220 VAC/50 Hz) 


(100 VAC/50 
Hz) 


SYSTEM 86/380 
MICROCOMPUTER 
SYSTEM. 


iRMX™ 86 OPERATING 
SYSTEM 


• Meets the open system 
requirements 
of the OEM 


• Expansion 
provided 
for eleven iSBC® 


boards and one 8-inch standard 
peripheral 
in two desk-top 
or rack- 
mount 
chassis 


• MULTIBUS® system 
bus 
multiprocessor 
architecture 


• Open to VLSI extensions 
through 
standard 
hardware 
modules 
and 
interfaces 


• High-performance 
computing 
with the 


iAPX 86/20 processor 
set (8086 16-bit 
CPU and 8087 numeric 
processor) 


• Open to software 
extensions 
with 


Intel® (PASCAL-86, 
FORTRAN-86) and 
independent 
software 
vendor (BASIC, 
COBOL, C) languages 


• Supported 
by iRMX™ 86, Intel's 
VLSI 
operating 
system 


• 35MB Winchester 
disk drive and 1MB 
diskette 
drive for program 
and data 


storage, 
plus backup 


• 384KB of high-speed 
RAM memory 
for 
multiple 
job and task execution 


• Extensive 
self-test 
routines 
to ensure 
reliable 
operation 
and enhance 
fault 
isolation 


The SYSTEM 86/380 Microcomputer 
System 
is a comprehensive, 
integrated 
hardware/software 
package 
designed 
for the OEM, yielding 
all the benefits 
of the latest advances 
in VLSI technology 
and performance 
without 
requiring 
complex 
system 
integration. 
Substantial 
expansion 
capacity 
is provided 
for 
both 
MUL TIBUS boards and an additional 
8-inch standard 
peripheral, 
allowing 
large computing 
systems 
to be 
built quickly 
to take advantage of rapidly-changing 
OEM opportunities. 
Based on industry 
standards 
estab- 
lished for. the MUL TIBUS system 
bus (IEEE-796) and 8-inch peripherals, 
the system 
also provides 
standar- 
dized software 
interfaces 
through 
the Universal 
Development 
Interface 
(UDI) available 
in Intel's 
iRMX 86 
VLSI real-time 
multitasking 
operating 
system. 
Computing 
performance 
three to five times 
that of smaller 
minicomputers 
is made possible 
by the iAPX 86/20 VLSI processor 
set, supported 
by the large 
RAM 
memory 
system 
and high-capacity 
mass storage 
devices. 
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The following 
are trademarks 
of Inlel 
Corporation 
and may 
be used 
only 
to describe 
Intel 
products: 
Intel, 
CREDIT, 
Index, 
Insite, 
Intellee, 
library 
Manager, 
Megachassis, 


Micromap. 
MULTIBUS, 
PROMPT, 
UPI, /lScope, 
Promware, 
MeS, 
ICE, iRMX, 
iSSe, 
iSBX, 
iSXM, 
MULTICHANNEL, 
MULTI MODULE 
and 
iCS. Intel 
Corporation 
assumes 
no respon· 
sibility 
for the use of any circuitry 
other 
than circuitry 
embodied 
in an Intel prOduct 
No other 
cirCUlt 
patent 
licenses 
are implied. 
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210484-001 


Designed for OEM Open Systems 
Market Requirement 


The 
SYSTEM 
86/300 
family 
of 
microcomputer 
systems 
are designed 
to meet the emerging 
OEM 
systems 
market 
requirement 
for "open" 
systems. 


Open-systems 
requirements 
demand 
that the sys- 
tem 
be (1) open 
to 
easily 
absorb 
the 
next 
two 
generations 
of VLSI microcomputers, 
(2) open to 
instantly 
leverage 
off industry 
standard 
hardware 
modules 
and interfaces 
(such 
as the MULTIBUS 
and iSBX buses), 
(3) open 
to easily 
tap industry 
standard 
software 
from Intel and independent 
ven- 
dors, 
(4) open 
to 
industry 
standard 
data 
com- 
munication 
interconnections, 
and 
(5) open 
to 
allow the OEM to participate 
at any level of integra- 
tion: systems, 
boards and components. 
The open 
SYSTEM 
86/300 
microcomputer 
family 
provides 
the OEM with 
instant 
access 
to'VLSI 
technology, 


the instant 
leverage 
and stability 
of software 
and 
hardware 
standards 
and documentation 
and the 


PRINTER 
INTERFACE 
(50·PIN 
PARALLEL 
110) 


USER TERMINAL 
INTERFACE 
(RS232) 


iSBC' 
86130 
SINGLE 
BOARD 
COMPUTER 
• 
iAPX 86120 PROCESSOR 
• 
128K BYTES 
RAM 
• 
32K BYTES PROM 


iSBC' 
215 
WINCHESTER 
DISK 
CONTROLLER 


DRIVE 
EXPANSION 
@ 


5M 
BYTES 
WINCHESTER 
DISK 


only design approach 
to keep pace with VLSI tech- 


nology. 


PROCESSOR 
SECTION 


·Central 
Processor 
- 
The controlling 
element 
of 


SYSTEM 
86/380 
is the 
iSBC 86/30 Single 
Board 
Computer. 
The central 
processor 
of the iSBC 86/30 
board 
is the powerful 
16-bit 8086, operating 
at 5 
MHz with the 8087 Numeric 
Processor 
Extension 
installed 
on the iSBC 337 Math expansion 
board. 


The architecture 
of this 
VLSI processor 
includes 


four 
16-bit 
byte-addressable 
registers 
and 
two 


.16-bit index 
registers, 
accessible 
by a total 
of 24 
operand 
addressing 
modes for complex 
data han- 
dling 
and flexible 
memory 
addressing: 


Memory 
- 
Resident 
on the iSBC 86/30 board are 
128KB of high-performance 
dual-ported 
RAM ac- 


cessible 
to both the local and MULTIBUS 
system. 


iSBC' 
056A 
MEMORY 
EXPANSION 
256K BYTES 
DYNAMIC 
RAM 


iSBXTM Expansion 
- 
The iSBC 86/30 board also 


supports 
two connectors 
for the iSBX bus, an ex- 


pansion 
bus allowing 
the user to add parallel 
or 


serial 
I/O, analog 
I/O, peripheral 
controllers, 
and 


other 
functions 
at low cost and without 
requiring 


the use of additional 
MULTIBUS 
board slots. 


Other 
Facilities 
- 
The processor 
board 
includes 


an RS232C serial channel 
for communication 
with 


a user-supplied 
terminal, 
through 
a connector 
at 


the back of the chassis. 
The SYSTEM 86/380 soft- 


ware 
configures 
this 
channel 
automatically 
for 


9.6K baud, but asynchronous 
baud rates of 110 to 


19.2K are available 
on the board. A 50-pin parallel 


I/O interface 
cabled to the back of the chassis 
sup- 
ports 
signal 
levels 
of the industry-standard 
Cen- 


tronics 
printer 
interface. 


NUMERIC 
PROCESSING 
EXTENSION 


Also included 
with the SYSTEM 86/380 is the iSBC 


337 Numeric 
Data Processor. 
This MULTIMODULE 


board contains 
the Intel 8087 Numeric 
Processsor 


Extension. 
The co-processor 
interface 
between 


the 8087 and the 8086 host CPU provides 
a simple 


means 
of extending 
the 
instruction 
set 
of the 


system 
with 
over 60 additional 
numeric 
instruc- 


tions 
supporting 
six additional 
data 
types. 
The 


data formats 
used in the SYSTEM 86/380 conform 


to the proposed 
IEEE floating 
point 
standard 
en- 


suring 
highly 
accurate 
results. 
Dramatic 
numeric 


performance 
improvements 
are provided 
by the 


8087 co-processor. 
For example 
a 50X improve- 


ment in the Whetstone 
benchmark 
over the stand- 
ard 8086 processor 
is afforded 
by the 8087 co-pro- 


cessor. 


The 8087 arithmetic, 
logarithmic, 
transcendental 


and trigonometric 
instructions 
are fully supported 


by ASSEMBLER-86, 
as well 
as other 
Intel 
high- 


level languages 
such as PUM-86, PASCAL-86 and 


FORTRAN-86. 


In addition 
to the 128KB of RAM on the processor 


board, the SYSTEM 86/380 also includes 
a 256KB 


memory 
expansion 
board. This brings 
the system 


RAM 
memory 
supplied 
with 
the 
base 
SYSTEM 


86/380 to 384KB. The memory devices 
used are the 


latest-technology 
64K-bit dynamic 
RAMs. Through 


the use of optional 
memory expansion 
boards, the 


total 
capacity 
of the SYSTEM 86/380 may be ex- 


panded to one megabyte; 
as an example 
of the ca- 
pabilities 
inherent 
in the open architecture 
of Intel 


systems, 
128K bytes 
of this 
expansion 
could 
be 


implemented 
with 
the 
iSBC 304 Memory 
Expan- 


sion MULTIMODULE, 
which 
increases 
the overall 


system 
performance 
by placing 
even more mem- 


ory on the single 
board 
computer 
and reducing 


MUL TIBUS data and instruction 
traffic. 


MASS STORAGE 


Winchester 
Disk Drive - 
The SYSTEM 86/380 con- 


tains a high performance 
35MB (32MB formatted) 


8-inch 
Winchester 
fixed-media 
disk 
drive for pro- 


gram and data storage. 
The drive has an average 


access 
time of 43 milliseconds 
and a transfer 
rate 


of 6.44 Mbits/sec. 


Diskette 
Drive - 
An 8-inch double-density/double- 


sided 
diskette 
drive 
with 
1M byte capacity 
is in- 


cluded 
in the base system. This high-density 
drive, 


which 
has an average access 
time of 91 millisec- 


onds 
and a transfer 
rate of 500Kbits/sec, 
can be 


used for both data storage 
and system 
backup. 


Intelligent 
Controller 
- 
The SYSTEM 86/380 uses 


the intelligent, 
8089-based 
iSBC 215 Winchester 


controller. 
This 
high 
performance 
interface 
con- 


tains 
firmware 
which 
is executed 
directly 
on the 


8089 processor. 
This I/O processor, 
coupled 
with 


an on board RAM buffer, off-loads 
a significant 
por- 


tion 
of disk 
I/O overhead 
from the host 8086 pro- 


cessor. 


Diskette 
Controller 
- 
In addition 
to 
the 
Win- 


chester 
control 
firmware, 
there 
is also 8089 firm- 


ware resident 
on the iSBC 215 board to control 
the 


iSBX 218 diskette 
controller. 
This controller 
plugs 


directly 
onto the iSBC 215 board via one of the two 


available 
iSBX connectors. 


Mass storage 
expansion 
beyond 
the single 
Win- 


chester 
and diskette 
drives 
configured 
with 
the 


system 
is easily accomplished 
by the OEM in the 


open 
position 
of the peripheral 
chassis. 
In addi- 


tion to the Winchester 
and diskette 
interfaces 
pro- 


vided 
with 
the 
system, 
Intel 
also 
can 
provide 
a 


MULTIBUS controller 
board and iRMX 86 software 


for SMD-compatible 
disk drives. 


System Chassis 


SYSTEM PACKAGING 
CONFIGURATION 


The SYSTEM 86/380 is packaged 
in two chassis. 


Module Package - 
This package contains 
a 14-slot 


cardcage, 
all of whose 
slots 
accept 
MULTIBUS- 


compatible 
boards 
with 
iSBC MULTIMODULE 
ex- 


pansion boards attached 
(See Figure 1). In addition, 


three of the slots are sufficiently 
far from adjacent 


slots 
to allow 
boards 
with 
iSBX MULTIMODULE 


boards 
to be inserted, 
with 
no penalty 
in loss of 


slots. Two of these wide slots and a third standard 


slot are utilized 
by the boards which 
make up the 
SYSTEM 
86/380, 
leaving 
eleven 
slots 
(one wide, 
ten narrow) for user expansion. 
110 cables run from 
the boards 
in the module 
package 
to connectors 
on 
the 
back 
of 
the 
package; 
interconnecting 
cables 
run from that 
point 
to the back of the pe- 
ripheral 
package. 


Figure 
1. Interior 
of SYSTEM 86/380 Module 
Package 


Peripheral 
Package 
- 
This 
package 
houses 
the 
Winchester 
and diskette 
drives (see Figure 2). One 
position, 
suitable 
for mounting 
any industry-stand- 
ard 8-inch peripheral 
drive, is available to the user. 


The two chassis 
may be used on a desk 
top or 
mounted 
(with 
user-supplied 
slides) 
in a user- 
furnished 
19" 
EIA 
equipment 
rack. 
The 
two 
packages 
are connected 
with 
a set of cables 
ap- 
proximately 
4.5 feet long. Knock-outs 
are available 
on the back 
panel 
of each chassis 
to allow 
the 
OEM to easily configure 
additional 
1/0 connectors 
into the system (see Figure 3). The SYSTEM 86/380 
has been designed 
to meet UL and CSAsafety 
and 
FCC EMI/RFI requirements 
. 
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Figure 2. Interior 
of SYSTEM 86/380 Peripheral 


Package 


VLSI OPERATING 
SYSTEM (iRMXTM86) 


The powerful 
iRMX 86 Operating 
System 
is an 


easy-to-use, 
comprehensive 
multiprogramming 


software 
system 
designed 
not 
only 
for 
the 


SYSTEM 
86/380, 
but for iAPX 86/88-based 
iSBC 


board and component 
level designs. 


Services 
provided 
by the 
RAM-based 
iRMX 
86 


Operating 
System 
include 
facilities 
for executing 


programs 
concurrently, 
sharing 
resources 
and in- 
formation, 
servicing 
asynchronous 
events, and in- 
teractively 
controlling 
system 
resources 
and utili- 


ties. 
In addition, 
the iRMX 86 Operating 
System 


provides 
all 
major 
real-time 
facilities 
including 


priority-based 
system 
resource 
allocation, 
means 


for concurrently 
monitoring 
and controlling 
multi- 


ple external 
events, 
real-time 
clock 
contrOl, 
inter- 


rupt management, 
and task dispatching. 
The iRMX 


86 Operating 
System contains 
the following 
mod- 


intel 


ules: an object-oriented 
nucleus; 
device 
indepen- 
dent 
basic 
and extended 
1/0 
systems; 
terminal 


handler; 
bootstrap 
and application 
loader; human 


interface 
with complete 
command 
line interpreter; 
and an interactive, 
object-oriented 
debugger. 


Because the modules 
and services 
provided 
by the 


operating 
system 
are user-selectable, 
application- 


specific 
operating 
systems 
can be created 
by 


iRMX 86 users. 
The iRMX 86 Operating 
System 


eliminates 
the need for custom 
operating 
system 


design, 
thus reducing 
development 
time, cost, ef- 
fort and risk. 


Development Support 


In addition 
to its capabilities 
as an OEM operating 


system, 
SYSTEM 86/380 and the iRMX 86 Operat- 


~D·.SYSTE~ 


~B6/3BO 


ing 
System 
provide 
application 
development 
languages 
and 
facilities 
to 
the 
OEM 
to 
allow 
development 
on the target 
system. 


iRMXTM 
UTILITIES 
PACKAGE 
(iRMXTM 
860) 


The iRMX 860 Utilities 
Package 
consists 
of the 
following 
software: 


iRMXTM 
86 EDIT - 
The iRMX 86 EDIT program 
pro- 
vides 
users 
with 
a powerful, 
sophisticated, 
line- 


oriented 
editing 
facility. 
EDIT delivers 
a range of 


capabilities 
suitable 
for novice users as well as ad- 
vanced 
capabilities 
for sophisticated 
users. 
Its 
key features 
include 
a macro processor 
capable of 
creating 
and executing 
complex 
strings 
of com- 


mands, which 
eases the editing 
chore, 
as well as 


INDEPENDENT 


SOFTWARE 
VENDOR 
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inter 


defining 
blocks 
of text 
which 
may be included 
anywhere 
in the text file. EDIT offers variable com- 


mand sourcing, 
symbolic 
line numbering 
and ref- 


erence 
by symbol. 
The facilities 
of EDIT allow 
users 
to create, 
maintain 
and manipulate 
exten- 
sive libraries 
of source code with minimal 
effort. 


iRMXTM 86 LINK/LOCATE 
- 
The iRMX 86 LINK! 


LOCATE program connects 
object 
modules 
which 
have 
been 
individually 
compiled 
into 
a single, 


relocatable 
object 
module. 
The input 
object 
code 
may have been produced 
by any object 
module 
format-compatible 
compiler. 
Output 
object 
mod- 
ules 
may be recombined 
into 
larger 
object 
mod- 


ules, 
allowing 
work 
from 
a large 
programming 
staff 
to be easily 
integrated 
into 
an application 
system. 


iRMXTM 86 
LIB 
- 
the 
iRMX 
86 
LIB 
"Library 
Manager" 
allows 
creation 
and maintenance 
of ob- 
ject 
module 
libraries. 
These 
libraries 
allow 
easy 


collection 
of related 
object 
code 
to reduce 
the 


overhead 
of maintaining 
many separate 
modules. 


Users may create new libraries, 
add and delete ob- 
ject 
modules, 
as well 
as list the contents 
of the 
library and their public 
symbols. 


PLlI'v1·86(iRMXTM 863) 


The PUM-86 compiler 
provides users with a power- 
ful, microcomputer-oriented 
system 
programming 
language. 
The PUM·80 
language 
was introduced 


in 1976 by Intel. 
It was the first 
microcomputer- 
oriented, 
block 
structured, 
high-level 
language 
available. 
Since 
1976, thousands 
of users, 
ship- 
ping 
over millions 
of microcomputer-based 
sys- 


tems 
have generated 
their 
system 
software 
with 
PUM-80 and PUM-86. 


PUM·86 is a compatible 
superset 
of PUM-80 which 
offers 
easy portability 
of software 
across 
the full 
range 
of microcomputers 
supplied 
by Intel. 
For 
more 
information 
about 
PLlM-86, 
see the 
PLIM 
86/88 Software 
Package data sheet (402175). 


FULL REALMATH 
SUPPORT 


The iRMX 86 languages 
support 
the REALMATH 
floating 
point 
standard. 
This 
allows 
users 
of all 


iRMX 
86 languages 
to access 
the 
iAPX 
86/20 
Numeric 
Data 
Processor 
using 
the 
iSBC 
337 
MULTI MODULE board. This numeric 
processor 
of- 
fers over 100 times greater performance 
than com- 
parable 
software-implemented 
algorithms, 
and 


reduces 
the system 
memory 
requirements 
by at 
least 
16KB. The REALMATH 
standard 
(proposed 
IEEE standard) 
provides 
universal 
consistency 
in 


results 
of numeric 
computations. 
The 
iRMX 86 


languages 
provide 
efficient 
object 
code 
genera- 


tion and access 
to the highest-performance 
float- 


ing point package available 
on microcomputers. 


COMPREHENSIVE 
SELF-TEST AND SYSTEM 


DIAGNOSTICS 


In order 
to ensure 
correct 
system 
operation 
and 


rapid location 
of both hardware and software 
prob- 


lems, 
the SYSTEM 86/380 is supplied 
with 
three 


levels of diagnostic 
routines: 


SCT (System 
Confidence 
Test) 
- 
Automatically 


executed 
at power on and system 
reset, the SCT 


performs 
a GO-NO GO check 
for the processors, 


memory and peripherals 
in the system. 
, 


SOT (System 
Diagnostic 
Test) - 
In the event that 


the SCT finds 
a system 
problem, 
the SDT may be 


executed 
by the user for a detailed 
analysis 
of the 


hardware 
status. 
This 
easy·to-use 
monitor-based 


program 
can perform 
tests on all hardware 
boards 


in the system 
and mass storage 
peripherals. 


SAT (System Analysis 
Test) - 
This diagnostic 
tool 


tests the integration 
of the hardware and software 


at the system 
level. This helps to isolate 
intermit- 


tent failures 
by running 
a load stress 
test on both 


hardware and software. 


SYSTEM DEBUGGIN~ 
TOOLS 


The iRMX 86 Operating 
System provides a compre- 


hensive 
tool 
for interactive 
software 
debugging. 


The debugger 
has two 
capabilities 
that 
greatly 


simplify 
the process 
of debugging 
a multitasking 


system. 
First, the debugger 
allows 
users to debug 


several tasks while 
the balance 
of the application 


system 
continues 
to run in real-time. 
Second, 
the 


debugger 
allows 
programmers 
to interactively 


view and modify 
system 
constructs 
as well as the 


system 
RAM and CPU registers. 
The debugger 
is 


structured 
to enable 
system 
designers 
to track 


system-wide 
problems 
easily. It can also remain in 


the final OEM application 
as a maintenance 
tool. 


The Intel 
software 
products 
listed 
above 
require 


the signing 
of an Intel 
Master 
Software 
License 


Agreement. 
All 
products 
include 
one year of up- 


date service. 
Software 
is shipped 
on floppy 
media 


in two 
object 
forms: 
1) a ready-to-run, 
fully 
con- 


figured 
system 
and 2) a configurable 
version 
of all 


software 
products. 


intel 


OPTIONAL 
INTEL® SOFTWARE 
SUPPORT 


In addition 
to ASM-86 and PUM-86 
compilers 
in- 


cluded 
in the base SYSTEM 86/380 the following 


Intel languages 
are available for use on the system: 


PASCAL·86 
(iRMXTM 861) - 
The PASCAL-86 
com- 


piler 
provides 
a strict 
implementation 
of the pro- 


posed 
ISO language 
standard. 
All 
source 
pro- 


grams 
are validated 
by the compiler 
to ensure 
its 


conformance 
to the standard. 
Many extensions 
to 


the 
language 
are available 
which 
allow 
PASCAL 


programs 
to be written 
specifically 
for microcom- 


puters. 
Separate 
module 
compilation 
and 
iAPX 


86/20,88/20 
Numeric 
Data Processor 
support 
are a 
few of its many features. The ISO standard "source 
evaluator" 
can be switched 
off to accept 
these ex- 


tensions. 
For more information 
on iRMX 86 PAS- 
CAL 
features, 
see the 
PASCAL" 86/88 
Software 
Package data sheet (121680). 


FORTRAN-86 
(iRMXTM 862) - 
The iRMX 86 FOR- 
TRAN compiler 
provides 
users total compatibility 


with 
existing 
FORTAN 
86 language-generated 


code, 
plus 
many hew language 
features 
provided 


by the 
FORTRAN 
77 language 
standard. 
These 


new features 
offer 
FORTRAN 
programmers 
many 
new capabilities, 
including 
"IF-THEN-ELSE", 
ran- 


dom access I/O and character 
variables. 
For a more 


detailed 
explanation 
of iRMX 86 FORTRAN, 
see 
the FpRTRAN 
86/88 Software 
Package rata 
sheet 


(400630). 


MULTIPROCESSING 
EXPANSION 


iMMX 
800 MULTlBUS® 
Message 
Exchange 
- 
The 


advanced 
design 
of the 
MUL T1BUS system 
bus 


coupled 
with 
the 
iMMX 
800 software 
package 


allows 
the SYSTEM 86/380 to easily 
support 
addi- 


tional 
8 andlor 16-bit Intel single 
board computers. 


This 
powerful 
option 
enables 
OEMs 
to increase 


the SYSTEM 86/380's 
general 
purpose 
processing 


power with 
boards such as the iSBC 86/05 (8 MHz 


8086) and 
iSBC 88/25 (5 MHz 8088), or the 
iSBC 


80/24 (5 MHz 8085). Intelligent, 
high-performance 
microprocessor-based 
boards 
such 
as the 
Ether- 


net' 
communications 
controller 
(iSBC 550 board), 


serial communications 
controller 
(iSBC 544 board) 
and analog 
measurement 
and control 
computer 
(iSBC 88/40 board) can greatly 
expand the capabili- 


ties and processing 
power of the SYSTEM 86/380. 


Independent 
Software 
Vendor Support 
- 
Through 
the use of the standard 
UDI (Universal 
Develop- 


ment 
Interface) 
a wide 
variety 
of language 
pro- 


ducts, 
both 
compilers 
and interpreters, 
are now 
available 
for 
use on iRMX 86 from 
independent 
software 
vendors. 
COBOL, 
BASIC and C are a few 
examples 
of the available 
languages. 
Contact 
your 
Intel sales representative 
for more information. 


System Options 


HARDWARE 


Any Intel MULTIBUS 
board may be installed 
by the 
OEM into the eleven 
available 
expansion 
slots 
in 
the system 
chassis. 
Over 40 MUL TIBUS boards are 
available 
from 
Intel, 
and more than 90 other 
ven- 
dors produce 
MULTI BUS-compatible 
products_ 
In 
addition, 
Intel 
manufactures 
iSBX 
Bus 
MUL TI- 
MODULE 
boards 
for use in any board's 
iSBX Bus 
connector, 
and 
iSBC 
Extension 
MULTI MODULE 
boards 
for 
memory 
and math 
co-processor 
addi- 
tions 
which 
are tightly-coupled 
to each individual 
board's 
architecture. 


In addition 
to the iRMX 86 operating 
system, 
the 
XENIX 
interactive 
multi-user 
operating 
system 
is 
also available 
for SYSTEM 86/380 computers. 
See 


the 
SYSTEM 
86/380X 
data 
sheet. 
Optional 
lan- 


guage 
products 
are available 
from 
both 
Intel and 
independent 
software 
vendors. 
Operatingsystem 
support 
for additional 
8085-, 8088- and 8086-based 
processor 
boards 
is available 
through 
the use of 
the iRMX 80 and iRMX 88 Operating 
Systems. 


Instruction 
- 
8, 16, or 32 bits 


Data - 
8/16 
bits 


NUMERIC 
CO-PROCESSOR 


Data - 
80 bits 


Instruction Cycle Time 


400 nanoseconds 
for fastest executable 
instructions 
(assuming 
5 MHz clock 
rate and the instruction 
is 
in the queue). 
1.0 microsecond 
for 
fastest 
executable 
instruc- 


tions 
(assuming 
5 MHz clock 
rate and the instruc- 


tion is not in the queue). 


Memory Capacity 


RAM - 
384K bytes supplied 
with the base system. 


Memory 
may be expanded 
to 1 megabyte. 


Interface 


EIA Standard 
RS232C 
signals 
provided 
and 
sup- 


ported. 


Serial 
- 
Configurable 
from 
110 
to 
19.2K 
baud 


asynchronous; 
SYSTEM 
86/380 
software 
config- 
ures the user terminal 
port 
for 9.6K baud 


Parallel 
- 
A 50-pin 
parallel 
I/O port 
that 
is sup- 


plied 
with 
signal 
levels 
compatible 
with 
the 
in- 
dustry 
standard 
Centronics 
printer 
interface 
(OEM 


supplied 
cable) 
, 


AC Requirements 


Module Package - 
1738W maximum power consump- 


tion; 10A @ 92-126 VAC, 60 Hz, single-phase 
(US); 6,3A 


@ 184 to 252 VAC, 50 Hz, (Eur); 13.8A @ 92-126 VAC, 
50 Hz single-phase 
(Japan) 


Peripheral 
Package 
- 
693W 
maximum 
power con- 
sumption; 
7.0A 
@ 92-126 
VAC, 60 Hz single-phase 


(US); 2.5A @ 184-252 VAC, 50 Hz (Eur); 7.0A@ 
92-126 


VAC, 50 Hz single-phase 
(Japan) 


Product Safety Standards 


The system 
is listed under UL standard 
114 Safety of 


Electronic Data Processing 
Units and Systems, It is al~o 


certified by the Canadian Standards Association, 
stand- 


ard C22.2 154-1975 Safety of Data Processing Equipment. 
The system complies 
with the International 
Electronics 


Commission 
standard 
IEC 435 Safety of Data Process- 


ing Equipment. 
The system also conforms to the appli- 
cable RFIIEMI requirements 
of FCC rule 47 CFR part 15 


subpart 
J, Emission 
Limits for Computing 
Devices. 


Temperature 
and Relative Humidity - 
15°C to 35°C 


dry bulb 
and 20% 
relative 
humidity 
to 80% 
relative 


humidity 
non-condensing 
subject 
to a maximum 
wet 


bulb temperature 
of 26°C. 
These conditions 
translate 


to a maximum 
relative humidity of 80% non-condensing 


up to 28,8°C which falls to a maximum 
relative humidity 


of 50% at 35°C 


Altitude 
- 
Sea level to 10,000 feet 


Vibration 
- 
0.0014 
inches 
peak-to-peak, 
5-25 Hz; 


0.0007 inches peak-to-peak, 
25-55 Hz; 0.3g O-to-peak, 


55-300 Hz 


Shock - 
1,Og for 11 ms 


Temperature 
- 
25°C to 60°C 


Relative 
Humidity 
- 
20% to 80% non-condensing 


Altitude 
- 
Sea level to 40,000 feet 


Vibration - 
0.008 inches peak-to-peak, 
5-25 Hz; 0.004 


inches peak-ta-peak, 25-55 Hz; 2.0g D-to-peak, 55-300 Hz 


Shock - 
15g for 11 ms 


Physical Characteristics 


Both 
the 
module 
package 
and 
the 
peripheral 


package 
have the same 
dimensions: 


Width 
- 
16.8 in. (42.6 em) 


Height 
- 
12.2 in. (31.1 em) 


Depth 
- 
21.0 in. (53.3 em) 


Weight 
- 
Module 
Package 
- 
55 
Ib 
(25 
kg); 


Peripheral 
Package 
- 70 Ib (32 kg) 


In 'addition 
to these 
two 
Packages, 
the chassis 
in- 


terconnecting 
cables 
weigh 
approximately 
5 Ib (3 


kg). 


Extensive System Documentation 


The SYSTEM 
86/380 is shipped 
with 
six documen- 


tation 
binders 
containing 
over 
28 
in-depth 


manuals 
on all aspects 
of hardware 
and software 


operation. 
A System 
Installation 
and Maintenance 


manual, 
in addition 
to a System 
Overview 
manual, 


is also 
included. 


Part Number 
Description 


SYS86380ABR 
KIT 
(220 VAC/50 Hz) 


SYS86380ACR 
KIT 
(100 VAC/50 Hz) 


SYSTEM 86/330X 
MICROCOMPUTER 
SYSTEM 
XENIX* 


• Meets the open system requirements 
of the OEM 


• Industry standard XENIX interactive 
operating system 


• Memory management and protection 
for the high performance 8 MHz 16-bit 
iAPX 86/10 processor 


• Standard language support includes C 
and ASSEMBLER-86. Other languages 
available soon 


• MULTIBUS®system bus (IEEE-796) 
multiprocessor 
architecture 


• 35MB Winchester 
and 1MB DS/DD 8" 
floppy for program, data storage and 
back-up 


• 384KB of high speed RAM memory to 
execute multiple-user 
applications 


• Extensive self-test routines for reliable 
operation and simple fault isolation 


• 5 serial ports included (expandable to 
nine ports) 


The Intel SYSTEM 86/330X 
Microcomputer 
System is an integrated, 
high-performance 
16-bit XENIX-based 
microcomputer 
system. The system, which is based on standard Intel MULTIBUS system bus board level 
products, 
comes complete 
with connections 
to five user terminals 
(expandable to nine), a state-of-the-art 
35MB Winchester 
disk, and a 1MB DSIDD floppy disk subsystem. 
In addition 
to the standard OEM multi- 
user operating 
system the SYSTEM 86/330X 
is also supplied 
with an efficient "e" compiler, 
editor, debug- 
ger and all other standard XENIX software . 


••••"f"."'·","" ~ 


• XENIX 
IS a trademark 
01 Microsoft 
Corporation 


The followmg 
are trademarks 
at Inlel Corporal Ion and may be used only to deSC:ftbe Intel produtlS 
Intel. CREDIT 
Index. InSlle. Inlellec. 
Library Manager. Megachassls 


Mlcromap, 
MUl TlBUS, PROMPT 
UPI. "Scope. 
Promware. 
MCS 
ICE. tRMX. 'ssc. 
,sex. tSXM. MULTICHANNEL 
MUl TlMODULE 
and les 
Intel Corparallan 
assumes 
no respon· 
Slbillty lor the use 01 any CirCUitry other than Circuitry embOdied tn an Inlel product 
No other CirCUit patent lIcenses 
are Implted 


Designed for OEM Open Systems 
Market Requirement 


The 
SYSTEM 
86/300 
family 
of 
microcomputer 
systems 
are designed 
to meet the emerging 
OEM 
systems 
market 
requiremeqt 
for "open" 
systems. 
Open-systems 
requirements 
demand 
that the sys- 
tem be (1) open to easily 
absorb 
the next two gen- 
erations 
of VLSI 
microcomputers, 
(2) open 
to in- 
stantly 
leverage 
off 
industry 
standard 
hardware 
modules 
and 
interfaces 
(such 
as MULTIBUS 
and 
iSBX buses), 
(3) open to easily 
tap industry 
stand- 
ard software 
from 
Intel 
and independent 
vendors, 
(4) open to industry 
standard 
data communication 
interconnections, 
and (5) open to allow 
the OEM to 
participate 
at 
any 
level 
of 
integration, 
systems, 
boards and components. 
The open SYSTEM 86/300 
microcomputer 
family 
provides 
the OEM with 
in- 
stant 
access 
to VLSI technology, 
and the instant 
leverage 
and 
stability 
of 
software 
and 
hardware 
standards 
and documentation. 


Open Systems Architecture Allows 
Multiple Levels of Integration 


The 
entire 
SYSTEM 
86/330X, 
both 
hardware 
and 
software, 
is built 
using 
standard, 
modular 
off-the- 
shelf 
Intel 
board 
level 
products 
and system 
soft- 


ware. The system 
is designed 
so that the OEM can 
easily 
tailor 
a custom 
system 
through 
the use of 
individual 
Intel 
board 
level products. 


The SYSTEM 
86/330X 
is a complete 
16-bit 
micro- 
computer 
system 
designed 
to execute 
UNIXt, 
the 
16-bit 
standard 
interactive 
multi-user 
operating 
system. 
The SYSTEM 
86/330X uses XENIX, 
a fully- 


licensed 
implementation 
of 
Bell 
Laboratories 
UNIX V7 that has been designed 
specifically 
to ex- 


ecute 
on the 
high-performance 
iAPX 86/10 
16-bit 
processor. 
The hardware 
of this 
XENIX 
system 
is 


based 
on the Intel 
SYSTEM 
86/330A. 
The addition 
of the Intel-supplied 
XENIX software 
and the iSXM 
100 XENIX 
System 
Extension 
Module 
which 
in- 


cludes 
four additional 
serial channels 
(expandable 


to nine), processor 
memory 
management 
and pro- 
tection, 
internal 
cables 
and 
mounting 
hardware, 


expand 
the 
capabil 
ity of the 
system 
to execute 


this 
interactive, 
multi-user 
operating 
system. 


The single 
board 
computer 
used 
in the 
SYSTEM 
86/330X is the MULTI BUS-based 
iSBC 66/30 board. 


The central 
processor 
of the iSBC 86/30 board 
is 


the powerful 
8 MHz 16-bit 8086. The architecture 
includes 
four 
16-bit 
byte 
addressable 
registers, 
two 16-bit index registers, 
all accessed 
by a total 


of 24 operand addressing 
modes for complex 
data 
handling 
and flexible 
memory 
addressing. 


The base SYSTEM 86/330X is supplied 
with 384KB 
of high 
speed 
RAM memory. 
There 
is 128KB of 
dual-ported 
RAM resident 
on the iSBC 86/30 pro- 


cessor 
board 
accessible 
to 
both 
the 
local 
and 
MULTIBUS system 
bus and can address 
up to one 


megabyte 
of main memory. 
The processor 
board 
includes 
an RS232C serial channel 
for the connec- 
tion of a user supplied 
terminal. 
Cabling to the rear 


panel 
of the 
system 
is provided. 
Asynchronous 
baud 
rates 
of 
110 to 9.6K are supported 
by the 
system. 
A parallel 
I/O interface 
is also available on 
the processor 
board. 


MEMORY 


In addition 
to the 128KB of dual-ported 
RAM on the 


iSBC 86/30 processor 
board, the SYSTEM 86/330X 


also includes 
a 256KB memory 
expansion 
board. 


This 
brings 
the 
system 
RAM 
memory 
supplied 


with 
the 
base 
SYSTEM 
86/330X to 
384KB. 
The 
memory 
used 
is the 
latest 
technology 
64K 
bit 
dynamic 
RAMs. Through 
the use of optional 
mem- 


ory expansion 
boards, 
the total 
memory 
capacity 
of the SYSTEM 86/330X may be expanded 
to one 
megabyte. 


MASS STORAGE 


Intelligent 
Controller 
- 
The 
SYSTEM 
86/330X 
uses 
the 
intelligent, 
8089-based 
iSBC 
215 Win- 


chester 
controller. 
This 
high 
performance 
inter- 
face contains 
firmware 
which 
is executed 
directly 


on the 
8089 processor. 
This 
intelligent 
I/O pro- 


cessor 
coupled 
with 
an on-board 
RAM buffer 
off- 


loads 
a significant 
portion 
of disk 
I/O overhead 


from 
the host 8086 processor. 
In addition 
to the 


Winchester 
control 
firmware, 
there 
is also 
8089 


firmware 
resident 
on the iSBC 215 board to control 


the 
iSBX 218 floppy 
disk 
controller. 
The floppy 


controller 
plugs 
directly 
onto the iSBC 215 board 


via one of the two available 
iSBX connectors. 
! 


Mass storage 
expansion 
beyond 
the single 
Win- 


chester 
and floppy diskette 
drives configured 
with 


the 
system 
is easily 
accomplished 
by the OEM 


through 
the use of daisy chain connectors 
on the 
back panel of the SYSTEM 86/330X chassis. 


Winchester 
Disk 
Drive 
- 
The SYSTEM 
86/330X 


contains 
a high 
performance 
35MB 
(32MB 
for- 
matted) 8" Winchester 
technology 
hard disk drive 


for program 
and data 
storage. 
The drive 
has an 


average access time of 43 ms and a transfer 
rate of 
6.44 Mbits/sec. 


Floppy Diskette 
Drive - 
A double-density/double- 
sided, 8", 1MB, floppy disk drive is included 
in the 
base system. This high-density 
floppy drive, which 
has an average access 
time and a transfer 
rate of 
500Kbits/sec, 
can be used for both data storage 
and system 
backup. 


iSXM™ 100 XENIX System 
Extension Module 


The iSXM 100 XENIX System 
Extension 
Module 
is 
composed 
of two user installed 
standard 
boards 
including 
the Intel iSBC 309 Memory 
Management 
MUL T1MODULE board, iSBC 534 4-port Serial Ex- 
pansion 
board, 
cables 
and 
mounting 
hardware. 


The addition 
of this kit allows 
the OEM to execute 
the XENIX interactive 
operating 
system. 


MEMORY 
MANAGEMENT 
AND 
PROTECTION 


The 
Intel 
iSBC 
309 
Memory 
Management 
MULTIMODULE 
board is designed 
to add memory 


management 
capability 
to the 
SYSTEM 
86/330X 


microcomputers. 
The 
iSBC 
309 
board, 
which 
operates 
at either 
5 or 8 MHz, plugs 
directly 
into 


the processor 
socket 
of the iSBC 86/30 processor 
board and it does not require any additional 
inter- 


face or power requirements. 


The architecture 
of the iSBC 309 Memory Manage- 
ment MUL TIMODULE 
board is specially 
designed 
to 
optimize 
the 
performance 
of 
the 
XENIX 


operating 
system. 
There is a set of eight registers 
on the iSBC 309 board that make up a system 
pro- 


cess map cache. Through 
software 
support 
in the 


XENIX operating 
system, 
this cache contains 
the 


memory 
locations 
of not only 
the XENIX 
kernel, 


but also the seven most 
recently 
used user pro- 
cesses. The Intel implementation 
of XENIX using a 
least-used 
process 
algorithm, 
(LUP), constantly 


replaces 
the map of the least recently 
used pro- 


cess with the map of the process about to become 
active 
into 
main memory. 
This cache 
of process 


maps allows 
the XENIX operating 
system 
to per- 


form 
context 
switching 
between 
users 
and 
the 


operating 
system 
much 
faster 
than conventional 
memory 
management 
schemes 
that 
necessitate 


the swapping 
of user addresses 
through 
a single 


set of registers. 


The iSBC 309 board provides 
two modes 
of 8086 


operation: 
a system (or privi leged mode) and a user 


mode. 
In the system 
mode the operating 
system 
can map the logical 
address 
space of a user mode 


process 
anywhere 
in 
the 
processors 
one 


megabyte 
address 
space. The logical 
memory 
is 


mapped 
into 2K byte blocks. 
Each block 
can be 


marked 
as non-existent, 
read only, 
or read/write 


memory. 
These 
operations 
are performed 
auto- 


matically 
by the XENIX operating 
system 
and are 


transparent 
to the user. 


In the 
user 
mode 
a process 
cannot 
alter 
the 


memory 
map or change 
the process 
number. 
De- 


pending 
on the XENIX configuration, 
up to 7 user 


processes 
(plus 
one system 
process) 
with 
inde· 


pendent 
memory 
maps can be actively 
mapped at 


one time. The ability 
to support 
multiple 
process 


mars 
reduces 
the operating 
system 
overhead 
by 


reducing 
the time spent loading 
the memory 
map. 


The XENIX operating 
system 
available 
from 
Intel 


takes 
full 
advantage 
of these 
powerful 
memory 


management 
features 
available 
on the iSBC 309 


board. For more detailed 
information 
on the iSBC 


309 Memory 
Management 
board refer to the iSBC 


308/309 Memory 
Management 
boards data sheet, 


number 210496·001. 


In addition 
to the one serial 
1/0 channel 
resident 


on the iSBC 86/30 
processor 
board, the iSXM 100 


package 
provides 
four 
additional 
ports 
through 


the 
use of an Intel 
iSBC 534 Serial 
Expansion 


board. 
These 
ports 
are easily 
connected 
to any 


standard 
RS232C terminal. 
When 
in a local 
en- 


vironment, 
asynchronous 
data 
rates 
up to 9600 


baud are supported. 


The iSBC 534 board 
is shipped 
fully 
configured 


and ready to plug in the SYSTEM 86/300X 
micro- 


computer. 
The 
board 
interfaces 
directly 
to the 


system 
through 
the industry 
standard 
(IEEE-796) 


MUL TIBUS 
system 
bus. 
Additional 
iSBC 
534 


boards 
may 
be added 
by the 
user 
to 
expand 


beyond 
the 4 additional 
serial 
1/0 ports 
supplied 


with the iSXM 100 package. 


INSTALLATION 


The iSXM 100 XENIX Extension 
Module is designed 


to 
be field 
installed 
into 
any iSBC 86/30-based 


SYSTEM 86/330X 
microcomputer. 
An installation 


guide giving detailed 
instructions 
is included 
with 


the iSXM 100 Kit. Total 
installation 
time 
for the 


hardware kit is estimated 
to be less than one hour. 


Complete 
hardware 
installation 
can also be pro- 


vided 
by Intel Field Service 
Engineers 
for an op- 


tional 
fee. Contact 
the local Intel Sales Office 
or 


Intel distributor 
for more information 
on field serv- 


ice installation. 


SYSTEM CHASSIS 


The chassis 
used in the SYSTEM 86/330X 
is the 


compact 
iSBC 680 Multistore 
User System 
Pack- 
age. This chassis may be used either as a desk-top 
unit or, with 
user supplied 
rack slides, 
as a rack- 


mount 
system. 
This 23.0" x 16.75" x 12.25" pack- 
age houses up to six MULTIBUS cards. The 8" Win- 
chester 
disk 
drive 
and 8" 
floppy 
disk 
drive 
are 


housed in the iSBC 680 package with simple slide- 
in, slide-out 
service 
access. 
In addition 
to 
pro- 


viding 
the necessary 
voltages 
for the MUL T1BUS 


cards, 
the efficient 
switching 
power supply 
also 


provides 
the 24 volts 
needed for the DC powered 


Winchester 
drive. The SYSTEM 86/330X 
has been 


designed 
to meet UL, CSA, FCC and VDE safety 


and EMI/RFI requirements. 
A 50-pin parallel 
con- 


nector as well as connectors 
to the RS232 channels 


and additional 
floppy 
and Winchester 
disk drives 


are supplied 
with 
the SYSTEM 86/330X. 
Cut·outs 


are also available 
for OEM supplied 
connectors. 


GENERAL 
DESCRIPTION 


The SYSTEM 86/330X 
executes 
the industry 
stand- 


ard, interactive 
operating 
system, XENIX. XENIX is 


a fully-licensed 
Intel 8086 adaptation 
of the Bell 


Laboratories 
Version 
7 UNIX operating 
system. 


The 
XENIX 
system 
is an 
interactive, 
protected 


multi-user, 
multitasking 
operating 
system 
with 
a 


powerful, 
flexible 
human interface. 
The operating 


system 
is well 
suited 
to 
applications 
requiring 


multiple 
persons 
running 
independent, 
terminal· 


oriented 
jobs. 
Example 
applications 
include 
dis· 


tributed 
data processing, 
business 
data process· 


ing, 
software 
development 
and 
engineering 
or 


scientific 
data analysis. 


The differences 
between 
XENIX and UNIX V7 can 


either 
be classified 
as improvements 
or enhance- 


ments 
over 
the 
standard 
Bell 
Laboratories 
pro· 


duct. 


Improvements 
are 
changes 
that 
are 
made 
to 


enhance 
reliability 
and 
performance 
of 
the 


operating 
system 
but are transparent 
to the user. 


Enhancements 
are new features 
to the operating 


system which applications 
software 
programmers 


can take advantage 
of. 


The major improvements 
and enhancements 
that 


are available in Intel's version of the XENIX operat- 
ing system running on the SYSTEM 86/330X 
micro· 


computer 
are as follows: 


Automatic 
Disk Recovery 
- 
XENIX writes 
infor- 


mation 
on the disk in a more structured 
manner. 


Unlike UNIX, XENIX is able to recover information 
on the disk in the event of a system 
crash (unless 


there is a media failure). A special program, FSCK, 
cleans and restructures 
an unhealthy 
disk. 


Size and Speed - 
The implementation 
of XENIX 


used in the SYSTEM 86/330X 
has been optimized 


for both the 8086 microprocessor 
and for use on 


the hardware offered on the Intel system. Specific 
improvements 
have been made in such areas as 


memory 
management, 
serial 
I/O drivers 
and disk 


drivers to name a few. 


Floating Point - 
Floating point routines are moved 


from 
each 
individual 
program 
to a single 
copy 


located 
in the kernel. 
This saves memory 
space 


and improves 
system 
performance. 


System 
Configuration 
- 
To 
make 
it 
easier 
to 


generate a new XENIX system there is a new inter- 
active 
configuration 
utility 
supplied 
with 
the 


system 
to allow the user to specify 
device drivers, 
disk 
buffers, 
memory 
size etc. For more informa- 


tion on other enhancements 
and improvements 
to 


the XENIX operating 
system 
please 
refer to the 


Intel XENIX data sheet number 
210503-001. 


Scatter 
Loading 
- 
In conjunction 
with 
the iSBC 


309 
Memory 
Management 
board 
used 
in 
the 


SYSTEM 86/330X a sophisticated 
memory 
alloca- 


tion 
algorithm 
is used 
to ensure 
the 
maximum 


memory 
utilization 
and 
minimize 
system 
swap- 


ping. Unlike most minicomputer 
implementations 


of UNIX, which 
need large contiguous 
blocks 
of 


memory, 
XENIX running 
on the SYSTEM 86/330X 
can load multiple 
small 2K blocks 
of a users pro- 
gram 
into 
non-contiguous 
memory. 
This 
allows 


the operating 
system 
to utilize 
memory 
more effi- 


ciently 
and significantly 
reduces memory fragmen- 
tation and system swapping for higher performance. 


The 
XENIX 
operating 
system 
programs 
can 
be 


described 
as being in three major categories: 


Kernel 
- 
The 
kernel 
manages 
data 
storage, 
schedules 
tasks, 
manages 
main memory 
and pe- 


ripherals. 


Shell - 
This program 
is the human interface 
that 


interprets 
the 
commands 
typed 
by a user. 
The 


shell calls 
in user programs 
from storage 
and ex- 


ecutes 
them 
one at a time 
or concurrently 
in a 


series called a pipe. 


Utility 
Programs 
- 
These 
programs 
perform 
a 


number 
of 
system 
routines 
such 
as compiling, 


editing, 
file maintenance, 
etc. 


Device Independent 
I/O - 
Application 
software 
is 


written 
with 
device 
independent 
I/O. This allows 


the 
user 
to define 
the 
peripheral 
device 
at run 


time. 


Tree·structured 
File 
Directory 
and 
Task 
Hierar- 
chies 
- 
Users can access 
information 
on secon- 
dary storage 
by referring 
to a file with 
its ASCII 


name. The names of files 
stored 
on a device 
are 


stored 
in special 
files called directories. 
As direc· 


tories 
are themselves 
named files, 
the XENIX file 


system 
allows 
directories 
to contain 
the names of 


other 
directories. 
This 
structure 
is 
useful 
for 


isolating 
collections 
of files 
particular 
to an ap- 


plication, 
and for tailoring 
system -data to the re- 


quirements 
of users and applications 
sharing stor- 


age devices. 


Re·entrant/Shared 
- 
The XENIX system 
automati· 


cally 
separates 
code and data. This allows 
both 


systems 
programs 
such as editors 
and compilers 


as well 
as user code 
to be both 
shared 
and re- 


entrant. 
This method of memory 
utilization 
results 


in a more efficient 
and higher performance 
system. 


System 
Accounting 
and Security 
Access 
Protec· 


tion - 
The XENIX system has a complete 
security 


system 
for both system 
and file access. 
All data 


concerning 
system usage is also available for user 


accounting 
programs, 
and system 
tuning. 


In addition 
to 
the 
operating 
system 
itself, 
the 


XENIX system 
includes 
all of the support 
software 


developed 
by 
Bell 
Laboratories 
that 
has 
been 


added to the UNIX system 
during 
the last decade. 


It includes: 


• 
Microsoft 
implementation 
of 
the 
C language 
compiler 


• 
Text editing 
and typesetting 
software 


• 
Subroutine 
libraries 


• 
Assembler 
and debugger 


• 
System 
software 
development 
tools 


COMPREHENSIVE 
SELF·TEST AND SYSTEM 


DIAGNOSTICS 


In order to ensure 
correct 
system 
operation 
and 


rapid location 
of both hardware and software 
prob- 


lems, 
the SYSTEM 86/330X is supplied 
with 
two 


levels of diagnostic 
routines: 


SCT (System 
Confidence 
Test) 
- 
Automatically 


executed 
at power on and system 
reset, the SCT 


performs 
a GO-NO GO condition 
for the proces- 


sors, memory 
and devices 
in the system. 


SOT (System 
Diagnostic 
Test) - 
In the event that 


the SCT finds a system 
problem, 
the SDT may be 


executed 
by the user for a detailed 
analysis 
of the 


hardware 
status. 
This 
easy-to-use 
monitor 
pro- 


gram can perform 'tests on all hardware boards and 
mass storage 
peripherals 
in the system. 


In addition- 
to the XENIX 
operating 
system, 
the 


SYSTEM 
86/330X also 
includes 
a preconfigured 


version 
of iRMX 86, Intel's 
high performance 
real- 


time 
operating 
system. 
A fully-configurable 
ver- 


sion 
of iRMX 86 is also 
available. 
Contact 
your 


Intel 
sales 
engineer 
or your 
Intel 
distributor 
for 


more information. 


Instruction 
- 
8, 16, or 32 bits 


Data - 
8/16 bits 


Instruction Cycle Time 


250 nanoseconds 
for fastest executable instructions 


(assuming 
the instruction 
is in the queue). 


750 nanoseconds 
for fastest executable instructions 


(assuming 
the instruction 
is not in the queue). 


Memory Capacity 


RAM - 
384K bytes supplied 
with the base system. 
Memory 
may be expanded 
to 1 megabyte. 


Interface 


EIA Standard 
RS232C signals 
provided 
and sup- 


ported. 


Serial - 
5 RS232C connectors 
configurable 
from 
110 to 9.6K baud (asynchronous) 


Parallel 
- 
A 50-pin 
parallel 
I/O port that 
is sup- 


plied 
with 
signal 
levels 
compatible 
with 
the 
in- 


dustry standard 
Centronics 
interface 
printer (OEM 


supplied 
cable) 


AC Requirements 


5A @ 88 to 126 VAC, 60 Hz, single-phase 
(US only); 


2.5A 
@ 
176 to 
252 VAC, 
50 Hz, single-phase 


(Europe only); 5.5A @ 88 to 126 VAC, 50 Hz, single- 
phase (Japan). Maximum 
total power consumption 
693W. 


Product Safety Standards 


The system 
is listed under UL standard 
114 Safety 
of Electronic 
Data Processing 
Units and Systems. 


It is also 
certified 
by 
the 
Canadian 
Standards 
Association, 
standard 
C22.2 
154-1975 Safety 
of 
Data Processing 
Equipment. 
The system 
complies 


with 
the 
International 
Electronics 
Commission 
standard 
IEC 435 Safety of Data Processing 
Equip- 
ment. The system also conforms 
to the applicable 


RFI/EMI 
requirements 
of 
VDE 
0871/6.78, 
VDE 
0875/6.77 and FCC rule 47 CFR part 15 subpart 
J 
Emission 
Limits 
for Computing 
Devices. 


Temperature 
- 
15°C to 35 °c 


Relative Humidity 
- 
20% to 80% non-condensing 


over the operating 
temperature 
range* 


Vibration 
- 
1.0g @ 10 to 55 Hz 


*NOTE: The environmental combination of humidity and tem- 


perature together cannot exceed 26*C wet bulb. 


NON-OPERATING 


Temperature 
- 
- 25°C to 60°C 


Relative Humidity 
- 
20% to 80% non-condensing 


Vibration 
- 
1.0g for 5 ms shock 


Physical Characteristics 


Width 
- 
16.75 in. (42.55 em) 


Height 
- 
12.25 in. (31.12 cm) 


Depth - 
23.00 in. (58.42 cm) 


Weight 
- 
80 pounds 
(34.02 kg) 


Part Number 
Description 


SYS 86/330AAX 
Kit 
120V, 60 Hz 
(North American 
Version) 


SYS 86/330ABX Kit 
220V, 50 Hz 
(European 
Version) 


SYS 86/330ACX Kit 
100V, 50 Hz 
(Japanese 
Version) 


SYSTEM 86/330A 
MICROCOMPUTER 
SYSTEM 
iRMX™ 86 OPERATING SYSTEM 


• Open to VLSI extensions 
and a rapid 
upgrade path through 
standard 
VLSI 
hardware modules 
and interfaces 


• High performance 
16-bit iAPX 86120 
processor 
set (iSBC® 86130 
+ iSBC® 337 boards) 


• Full function 
iRMX™ 86 real·time, 
multitasking 
operating 
system 


• Intel® resident 
languages 
include 
PLlM·86 and ASSEMBLER-86. 
Intel® 


PASCAL·86, FORTRAN·86, plus 
independent 
software 
vendor 
languages 
(BASIC, COBOL, C), also 
available 


• MULTIBUS® system 
bus (IEEE·796) 
multiprocessor 
architecture 


• Compact 
desk· top or rack·mount 
integrated 
microsystem 


• 35MB Winchester 
and 1MB DSIDD 8" 


floppy 
for program, data storage and 
back-up. 


• 384KB of high speed RAM memory to 


execute 
multiple 
jobs and tasks 


• Extensive 
self· test routines 
for reliable 


operation 
and simple 
fault isolation 


The Intel SYSTEM 86/330A 
Microcomputer 
System 
is a comprehensive, 
real-time, 
integrated, 
16-bit hard- 


ware and software 
package 
designed 
to give the OEM the fastest 
path to high performance 
VLSI. The 


system, 
which 
is based on standard 
Intel MULTIBUS system 
bus board level products, 
also incorporates 
the iRMX 86 VLSI operating 
system, 
state-of-the-art 
high-capacity 
mass storage 
and high-density 
RAM 


memory boards. In addition 
to the 8086 general purpose microprocessor, 
the system 
provides 3 to 5 times 
the numeric 
performance 
of low-end minicomputers 
through 
the use of the 8087 numeric 
data processor. 


The system's 
capabilities 
can be greatly 
expanded 
through 
the use of additional 
general 
purpose 
pro- 


cessors 
and intelligent 
I/O boards. 


The following 
are trademarks 
of Inlel 
Corporation 
and may be used only 
10 describe 
Inlel 
products: 
Intel, 
CREDIT, Index, 
Insite, 
Inleltec, 
Library 
Manager, 
Megachassis. 


Mlcromap, 
MULTIBUS, 
PROMPT, 
UPI, ,.Scope, 
Promware. 
MeS, 
ICE, iAMX. 
iSBC, 
iSBX. 
lSXM, 
MULTICHANNEL, 
MULTI MODULE 
and iCS. Intel 
Corporation 
assumes 
no respon- 


sibility 
tor the use 01 any circuitry 
other 
than circuitry 
embodied 
In an Intel prodUct. 
No other circuit 
patent 
licenses 
are Implied 


DESIGNED 
FOR OEM OPEN SYSTEMS 
MARKET 
REQUIREMENT 


The 
SYSTEM 
86/300 
family 
of 
microcomputer 


systems 
are designed 
to meet the emerging 
OEM 


systems 
market requirement 
for "open" 
systems. 
Open-systems 
requirements 
demand t~at the sys· 


tem 
be (1) open 
to easily 
absorb 
the 
next 
two 


generations 
of VLSI microcomputers, 
(2) open to 


instantly 
leverage 
off industry 
standard 
hardware 
modules 
and interfaces 
(such as MULTIBUS 
and 


SBX), (3) open to easily tap industry 
standard 
soft- 
ware from Intel and independent 
vendors, (4) open 


to 
industry 
standard 
data 
communication 
inter- 
connections, 
and (5) open to allow the OEM to par- 


ticipate 
at 
any 
level 
of 
integration, 
systems, 


boards 
and 
components. 
The 
open 
SYSTEM 


86/300 
microcomputer 
family 
provides 
the 
OEM 


with instant access to VLSI technology, 
and the in- 


stant 
leverage and stability 
of software 
and hard· 


ware standards 
and documentation. 


OPEN 
SYSTEMS 
ARCHITECTURE 
ALLOWS 
MULTIPLE 
LEVELS 
OF INTEGRATION 


The entire 
SYSTEM 86/330A, 
both 
hardware 
and 


software, 
is built 
using standard, 
modular 
off-the- 


ISBX'· 
218 


FLEXIBLE 
DISI( 


CONTROLLER 


ISBC¢058A 


2581( RAM MEMORY 
BOARD 


shelf 
Intel board level products 
and system 
soft- 


ware. The system 
is designed 
so that the OEM can 
easily tailor 
a custom 
system 
through 
the use of 


individual 
Intel products 
needed to tailor a custom 
system. 
Through 
the 
use 
of 
industry 
standard 
modules 
and interfaces, 
the OEM can perform 
his 


own 
system 
integration 
without 
changing 
soft- 


ware code, thus lowering 
product 
cost. 


The single 
board computer 
used in the SYSTEM 
86/330A is the MUL T1BUS-based iSBC 86/30 board. 
The central 
processor 
of the iSBC 86/30 board is 
the powerful 
8 MHz 16-bit 8086 (5 MHz when used 


with the 8087 numeric 
co-processor). 
The architec- 


ture 
includes 
four 
16-bit byte addressable 
regis- 


ters, two 16-bit index registers, 
all accessed 
by a 


total of 24 operand addressing 
modes for complex 


data handling 
and flexible 
memory 
addressing. 


The base SYSTEM 86/330A is supplied 
with 384KB 
of high 
speed 
RAM memory. 
There 
is 128KB of 


dual-ported 
RAM resident 
on the iSBC 86/30 pro- 


cessor 
board 
accessible 
to 
both 
the 
local 
and 


MULTI BUS system 
bus and can address 
up to one 


megabyte 
of main memory. 
The processor 
board 


includes 
an RS232C serial channel 
for the connec- 


tion of a user supplied 
terminal. 
Cabling 
to the rear 


panel 
of the 
system 
is provided. 
Asynchronous 


baud rates of 110 to 19.2K are supported 
by the 


ISBC¢ 215 
WINCHESTER 
DISI( 


CONTROLLER 


system. 
A parallel 
I/O interface 
cabled to the back 
of the chassis 
is also supplied 
with 
the SYSTEM 
86/330A. This 50-pin cable 
supports 
the industry 
standard 
Centronics 
printer 
signals. 


NUMERIC 
PROCESSING 
EXTENSION 


Also 
included 
with 
the base SYSTEM 86/330A is 
the 
iSBC 
337 
Numeric 
Data 
Processor. 
This 
MULTIMODULE 
board contains 
the Intel 8087 nu- 
meric 
co-processor. 
The 
co-processor 
interface 
between 
the 8087 and the 8086 host CPU provides 
a simple 
means of extending 
the instruction 
set of 
the 
system 
with 
over 60 additional 
numeric 
in- 


structions 
supporting 
six 
additional 
data 
types. 


The data 
formats 
used 
in the 
SYSTEM 
86/330A 
conform 
to 
the 
proposed 
IEEE 
floating 
point 
standard 
insuring 
highly 
accurate 
results. 


Dramatic 
numeric 
performance 
improvements 
are 
provided 
by the 8087 co-processor. 
For example 
a 
50X improvement 
in the 
Whetstone 
benchmark 


over the standard 
8086 processor 
is afforded 
by 
the 8086 numeric 
co-processor. 


The 8087 arithmetic, 
logarithmic, 
transcendental 
and trigonometric 
instructions 
are fully supported 
by ASM-86, 
as well 
as other 
Intel 
higher 
level 
languages 
such 
as 
PLlM-86, 
PASCAL-86 
and 
FORTRAN-86. 


MEMORY 
EXPANSION 


In addition 
to the 128KB of dual-ported 
RAM on the 


iSBC 86/30 processor 
board, the SYSTEM 86/330A 
also includes 
a 256KB memory 
expansion 
board. 
This 
brings 
the 
system 
RAM 
memory 
supplied 
with 
the 
base 
SYSTEM 
86/330A 
to 
384KB. 
The 
memory 
used 
is the 
latest 
technology 
64K 
bit 
dynamic 
RAMs. 
Through 
the 
use 
of 
optional 
memory 
expansion 
boards, 
the 
total 
memory 


capacity 
of the SYSTEM 86/330A may be expanded 
to one megabyte. 


Winchester 
Disk 
Drive - 
The SYSTEM 86/330A 


contains 
a high 
performance 
35MB 
(32MB 
for- 


matted) 8" Winchester 
technology 
hard disk drive 


for program 
and data storage. 
The drive 
has an 


average access time of 43 ms and a transfer 
rate of 
6.44 Mbits/sec. 


Floppy Diskette 
Drive - 
A double-density/double- 
sided, 8", 1MB, floppy disk drive is included 
in the 
base system. This high-density 
floppy drive, which 
has an average access 
time and a transfer 
rate of 
500Kbits/sec, 
can be used for both data storage 
and system 
backup. 


Intelligent 
Controller 
- 
The 
SYSTEM 
86/330A 


uses 
the 
intelligent, 
8089-based 
iSBC 
215 Win- 


chester 
controller. 
This 
high 
performance 
inter- 


face contains 
firmware 
which 
is executed 
directly 


on the 
8089 processor. 
This 
intelligent 
I/O pro- 


cessor 
coupled 
with 
an on-board 
RAM buffer 
off- 


loads 
a significant 
portion 
of disk 
I/O overhead 


from 
the host 8086 processor. 
In addition 
to the 


Winchester 
control 
firmware, 
there 
is also 
8089 


firmware 
resident 
pn the iSBC 215 board to control 


the 
iSBX 218 floppy 
disk 
controller_ 
The floppy 


controller 
plugs directly 
onto the iSBC 215 board 


via one of the two available 
iSBX connectors. 


Mass storage 
expansion 
beyond 
the single 
Win- 


chester 
and floppy diskette 
drives configured 
with 


the 
system 
is easily 
accomplished 
by the 
OEM 


through 
the use of daisy chain connectors 
on the 


back panel of the SYSTEM 86/330A chassis. 
In ad- 


dition 
to the Winchester 
and floppy 
interfaces 
pro- 


vided 
with 
the system, 
Intel 
also 
can 
provide 
a 


board 
level 
interface 
and 
iRMX 
86 software 
for 


SMD compatible 
disk drives. 


SYSTEM 
CHASSIS 


The chassis 
used in the SYSTEM 86/330A 
is the 


compact 
iSBC 680 Multistore 
User System 
Pack- 


age. This chassis 
may be used either as a desk-top 


unit or, with 
user supplied 
rack slides, 
as a rack- 


mount 
system. 
This 
21.0" 
x 16.75" 
x 12.25" 


package 
houses 
up to six MULTIBUS 
cards 
(two 


available 
for expansion 
in the SYSTEM 86/330A). 


The 8" Winchester 
disk 
drive and 8" floppy 
disk 


drive are housed in the iSBC 680 package with sim- 
ple slide-in, 
slide-out 
service access. 
In addition 
to 


providing 
the 
necessary 
voltages 
for 
the 


MULTIBUS 
cards, 
the 
efficient 
switching 
power 


supply 
also provides 
the 24 volts 
needed 
for the 


DC 
powered 
Winchester 
drive. 
The 
SYSTEM 


86/330A has been designed 
to meet UL, CSA, FCC 


and VDE safety 
and EMI/RFI 
requirements. 
Sup- 


plied with 
the SYSTEM 86/330A, a 50-pin parallel 


connector, 
are connectors 
for the RS232C channel 


and additional 
floppy 
and Winchester 
disk drives. 


Cut-outs 
are also available 
for OEM supplied 
con- 


nectors. 


System Software 


As well 
as being 
the target 
system 
for OEM ap- 


plications, 
the SYSTEM 86/330A can also be used 


for iRMX 86 software 
development. 


VLSI OPERATING 
SYSTEM 
(iRMXTM 86) 


The powerful 
iRMX 86 Operating 
System 
is an 


easy-to-use, 
real-time 
multitasking 
software 
sys- 


inter 


tem designed not only for the SYSTEM 86/330A, 
but for iAPX 86/88-based iSBC board and com- 
ponent level designs. 


Services provided by the RAM·based iRMX 86 
Operating System include facilities for executing 
programs concurrently, sharing resources and in- 
formation, servicing asynchronous events, and in- 
teractively controlling system resources and utili- 
ties. In addition, the iRMX 86 Operating System 
provides all major real-time facilities, 
including 


priority-based system resource allocation, means 
for concurrently monitoring and controlling multi- 
ple external events, real-time clock control, inter- 
rupt management, and task dispatching. The iRMX 


~ 


;I!~ -Il 
!: •• 
I~- 


SYSTEM 
O8I330A 


86 Operating 
System contains 
the following 


modules: an object-oriented 
Nucleus; Device In- 


dependent Basic and Extended I/O Systems; Ter- 
minal 
Handler; 
Bootstrap 
and 
Application 


Loaders; Human Interface with complete com· 
mand line interpreter; and an interactive, object- 
oriented Debugger. 


Because the modules and services provided by the 
operating system are user selectable, application 
specific 
operating 
systems can be created by 


iRMX 86 users. The iRMX 86 Operating System 
eliminates the need for custom operating system 
design, thereby reducing development time, cost, 
effort and risk. 


INDEPENDENT 


SOFTWARE 


VENDOR 
LANGUAGES 


/ 
UNIVERSAL 
RUN·TlME 
INTERFACE 
(\lDII 
~ 
~,.-------~~® 


OR 
~ 
BOARD LEVEL 


~ 
DESIGNS 


< MULTIBUS' SYSTEM BUS:> 


inter 


iRMXTM UTILITIES PACKAGE (iRMXTM860) 


The iRMX Utilities 
Package consists 
of the follow- 


ing software: 


iRMXTM86 EDIT - 
The iRMX 86 EDIT program pro- 
vides 
users with 
a powerful, 
sophisticated, 
line- 
oriented 
editing 
facility. 
EDIT delivers 
a range of 


capability 
suitable 
for novice users as well as ad- 


vanced 
capabilities 
for sophisticated 
users. 
Its 


key features 
include a macro processor 
capable of 


. creating 
and executing 
complex 
strings 
of com- 


mands, 
which 
ease the editing 
chore, 
as well as 


defining 
blocks 
of text 
which 
may be included 


anywhere 
in the text file. EDIT offers variable com- 


mand 
sourcing, 
symbolic 
line 
numbering 
and 


reference 
by symbol. 
The facilities 
of EDIT allow 


users 
to create, 
maintain 
and manipulate 
exten- 
sive libraries 
of source 
code with 
minimal 
effort. 


For more information 
on iRMX 86 EDIT, see the 


EDIT Software 
Package data sheet (143883). 


iRMXTM 86 LINK/LOCATE 
- 
The iRMX 86 LINK! 


LOCATE program connects 
object 
modules which 
have been 
individually 
compiled 
into 
a single, 


relocatable 
object 
module. 
The input object 
code 


may have been produced 
by any Object 
Module 


Format-compatible 
compiler. 
Output 
object 


modules 
may be recombined 
into 
larger 
object 


modules, 
allowing 
work from a large programming 


staff 
to be easily 
integrated 
into 
an application 


system. 


iRMXTM 86 LIB 
- 
the 
iRMX 
86 LIB 
"Library 


Manager" 
allows 
creation 
and maintenance 
of ob- 


ject 
module 
libraries. 
These 
libraries 
allow 
easy 


collection 
of related 
object 
code 
to reduce 
the 


overhead 
of maintaining 
many separate 
modules. 


Users may create new libraries, 
add and delete ob- 
ject 
modules, 
as well as list the contents 
of the 


library and their public 
symbols. 


PLlM·86 (iRMX™ 863) 


The PUM-86 compiler 
provides users with a power- 
ful, microcomputer-oriented 
system 
programming 


language. 
The PUM-80 Language 
was introduced 


in 1976 by Intel. 
It was the first 
microcomputer- 


oriented, 
block 
structured, 
high-level 
language 


available. 
Since 
1976, thousands 
of users, 
ship- 
ping 
over millions 
of microcomputer-based 
sys- 


tems 
have generated 
their 
system 
software 
with 


PUM-80 and PUM-86 .. 


PUM-86 is a compatible 
superset of PUM-80 which 


offers 
easy portability 
of software 
across 
the full 


range of microcomputers 
supplied 
by Intel. 
For 


more 
information 
about 
PLlM-86, 
see the 
PLIM 


86/88 Software 
Package data sheet (402175). 


FULL REALMATH 
SUPPORT 


The iRMX 86 Languages 
support 
the REALMATH 


floating 
point 
standard. 
This allows 
users 
of all 


iRMX 
86 languages 
to access 
the 
iAPX 86/20 


Numeric 
Data 
Processor 
using 
the 
iSBC 
337 


MUL TIMODULE 
board. These numeric 
processors 


offer 
over 
100 times 
greater 
performance 
than 


comparable 
software-implemented 
algorithms, 


and reduce the system memory requirements 
by at 


least 
16KB. The REALMATH 
standard 
(proposed 


IEEE standard) 
provides 
universal 
consistency 
in 


results 
of numeric 
computations. 
The iRMX 86 


Languages 
provide 
efficient 
object 
code genera- 


tion and access 
to the highest 
performance 
float- 


ing point package available on microcomputers. 


COMPREHENSIVE 
SELF·TEST AND SYSTEM 


DIAGNOSTICS 


In order 
to insure 
correct 
system 
operation 
and 


rapid location 
of both hardware and software 
prob- 


lems, the SYSTEM 86/330A is supplied 
with three 


levels of diagnostic 
routines: 


SCT (System 
Confidence 
Test) - 
Automatically 


executed 
at power on and system 
reset, the SCT 


performs 
a GO-NO GO condition 
for the proces- 


sors, memory and devices 
in the system. 


SOT (System 
Diagnostic 
Test) - 
In the event that 


the SCT finds a system 
problem, 
the SDT may be 


executed 
by the user for a detailed 
analysis 
of the 


hardware 
status. 
This 
easy-to-use 
monitor 
pro- 


gram can perform 
tests on all hardware 
boards in 


the system and mass storage peripherals. 


SAT (System Analysis 
Test) - 
This diagnostic 
tool 


tests the integration 
of the hardware and software 


at the system 
level. This helps to isolate 
intermit- 


tent failures 
by running 
a load stress test on both 


hardware and software. 


SYSTEM DEBUGGING TOOLS 


The iRMX 86 Operating 
System provides a compre- 


hensive 
tool 
for interactive 
software 
debugging. 


The Debugger 
has two capabilities 
that 
greatly 


simplify 
the process 
of debugging 
a multitasking 


system. 
First, the Debugger allows 
users to debug 


several tasks while the balance of the application 
system 
continues 
to run in real-time. 
Second, 
the 


Debugger 
allows 
programmers 
to interactively 


view and modify 
system 
constructs 
as well as the 


system 
RAM and CPU registers. 
The Debugger 
is 


structured 
to enable 
system 
designers 
to track 


system-wide 
problems 
easily. It can also remain in 


the final OEM application 
as a continuous 
mainte- 


nancetool. 


The Intel 
software 
products 
listed 
above 
require 


the signing 
of an Intel 
Master 
Software 
License 
Agreement. 
All products 
include 
1 year of update 


service. 
Software 
is shipped 
on floppy 
media 
in 
two 
object 
forms: 
1) a ready-to-run, 
fully 
con- 


figured 
system, 
and 2) a configurable 
version 
of all 


software 
products. 


OPTIONAL 
INTEL'" SOFTWARE 
SUPPORT 


In addition 
to ASM-86 and PUM-86 included 
in the 
base 
SYSTEM 
86/330A, 
the 
following 
Intel 
lan- 
guages 
are available 
for use on the system: 


PASCAL·86 (iRMXTM 861) - 
The PASCAL-86 com- 


piler 
provides 
a strict 
implementation 
of the pro- 
posed 
ISO language 
standard. 
All 
source 
pro- 
grams 
are validated 
by the compiler 
to ensure 
its 


conformance 
to the standard. 
Many extensions 
to 


the 
language 
are available 
which 
allow 
PASCAL 
programs 
to be written 
specifically 
for microcom- 
puters. 
Separate 
module 
compilation 
and 
iAPX 
86/20,88/20 
Numeric 
Data Processor 
support 
are a 


few of its many features. 
The ISO standard "source 


evaluator" 
can be switched 
off to accept 
these ex- 
tensions. 
For 
more 
information 
on 
iRMX 
86 
PASCAL features, 
see the PASCAL 86/88 Software 
Package data sheet (121680). 


FORTRAN·86 
(iRMXTM 862) - 
The iRMX 86 FOR- 
TRAN compiler 
provides 
users total 
compatibility 
with 
existing 
FORTAN 
86 language-generated 


code, 
plus many new language 
features 
provided 
by the 
FORTRAN 
77 language 
standard. 
These 
new features 
offer 
FORTRAN 
programmers 
many 
new capabilities, 
including 
"IF-THEN-ELSE", 
ran- 
dom access 
110 and character variables. 
For a more 
detailed 
explanation 
of iRMX 86 FORTRAN, 
see 
the FORTRAN 
86/88 Software 
Package data sheet 


(400630). 


iMMX 800 MUL T1BUS<'Message 
Exchange 
- 
The 


advanced 
design 
of the 
MUL TIBUS 
system 
bus 


coupled 
with 
the 
iMMX 
800 software 
package 
allows 
the SYSTEM 86/330A to easily support 
addi- 
tional8 
and/or 16-bit Intel single 
board computers. 


This 
powerful 
option 
enables 
OEMs 
to increase 


the SYSTEM 86/330A's 
general 
purpose 
process- 


ing power 
with 
boards 
such as the iSBC 86/05 (8 
MHz 8086) and 
iSBC 88/25 (5 MHz 8088). Intelli- 


gent, 
high 
performance 
microprocessor-based 
boards 
such 
as the 
Ethernet' 
communications 


controller 
(iSBC 
550 board), 
serial 
communica- 


tions 
controller 
(iSBC 
544 board) 
and 
analog 
- 


measurement 
and control 
computer 
(iSBC 88/40 


board) can greatly expand the capabilities 
and pro- 


cessing 
power of the SYSTEM 86/330A. 


Independent 
Software 
Vendor Support 
- 
Through 
the use of the standard 
UDI (Universal 
Develop- 


ment 
Interface) 
a wide 
variety 
of language 
pro- 


ducts, 
both 
compilers 
and interpreters, 
are now 


available 
for 
use on iRMX 86 from 
independent 


software 
vendors. 
COBOL, 
BASIC and C are a few 


examples 
of the available 
languages. 
Contact 
your 


Intel sales representative 
for more information. 


HARDWARE 


Any Intel MUL TIBUS board may be installed 
by the 


OEM into the two available 
expansion 
slots 
in the 


system 
chassis. 


Operating 
Systems 
- 
In addition 
to the high per- 


formance 
iRMX 86 real-time 
operating 
system, 
a 


version 
of the SYSTEM 86/330A 
is also available 


with 
the interactive 
XENIXt 
(UNIX' 
V7) operating 


system. 
See your 
Intel 
sales 
representative 
or 


distributor 
for more details. 


Languages 
- 
Optional 
language 
products 
are 


available 
from 
both 
Intel 
and independent 
soft- 


ware vendors. 
Operating 
system 
support 
for addi- 


tional 8085, 8088 and 8086-based processor 
boards 


is available 
through 
the use of iRMX 80, iRMX 88 


and iRMX 86 software. 
Multiprocessor 
software 


support, 
iMMX 
800, 
is also 
available 
for 
the 


SYSTEM 86/330A. 


• ETHERNET,s 
a trademark 
01 XerOll Corp 


r UNIX tS a lfademark 
01 Bell LaboraTories 


~ XENIX 
IS a lr~demark 
of 
MICrOSOfl 
Corp 


GENERAL 
PURPOSE PROCESSOR 


Instruction 
- 
8, 16, or 32 bits 


Data - 
8/16 bits 


Instruction 
Cycle Time 


400 nanoseconds 
for fastest executable 
instructions 
(assuming 
5 MHz clock 
rate and the instruction 
is 


in the queue). 


1.0 microseconds 
for fastest 
executable 
instruc- 
tions 
(assuming 
5 MHz clock 
rate and the instruc- 
tion is not in the queue). 


Memory Capacity 


RAM - 
384K bytes supplied 
with the base system. 


Memory 
may be expanded 
to 1 megabyte. 


Interface 


EIA Standard 
RS232C signals 
provided 
and sup- 


ported. 


Serial 
- 
Configurable 
from 
110 to 
19.2K 
baud 
(asynchronous) 


Parallel 
- 
A parallel 
I/O port that is supplied 
with 
signal 
levels 
compatible 
with 
the industry 
stand- 
ard 
Centronics 
interlace 
printer 
(OEM 
supplied 
cable) 


iSBX Bus Expansion 
- 
Two 16-bit iSBX connec- 
tors available 
for VLSI MULTI MODULE expansion 


AC Requirements 


6.5A @ 88 to 126 VAC, 60 Hz, single-phase (US only); 
3.25A 
@ 
176 to 252 
VAC, 
50 Hz, 
single-phase 


(Europe only); 6.5A @ 88 to 126 VAC, 50 Hz, single- 
phase 
(Japan). 
Maximum 
total 
power consumption 
693W. 


Product Safety Standards 


The system is listed under UL standard 114 Safety of 
Electronic 
Data Processing 'Units and Systems. 
It is 
also certified by the Canadian Standards Association, 
standard 
C22.2 154-1975 Safety of Data Processing 
Equipment. The system complies with the International 
Electronics 
Commission 
standard 
IEC 435 Safety of 
Data Processing 
Equipment. 
The system 
also con- 


forms to the applicable 
RFI/EMI requirements 
of FCC 
rule 47 CFR part 15 subpart 
J Emission 
Limits for 
Computing 
Devices. 


Environmental Requirements 


OPERATING 


Temperature 
and Relative Humidity - 
15°C to 35°C 


dry bulb and 20% relative 
humidity 
to 80% relative 


humidity 
non-condensing 
subject to a maximum 
wet 


bulb temperature 
of 26°C. These conditions 
translate 


to a maximum relative humidity of 80% non-condensing 
up to 28.8°C which falls to a maximum relative humidity 
of 50% at 35°C 


Altitude 
- 
Sea level to 10,000 feet 


Vibration 
- 
0.0014 
inches 
peak-to-peak, 
5-25 Hz; 


0.0007 inches peak-to-peak, 25-55 Hz; 0.3g O-to-peak, 
55-300 Hz 


Shock - 
1.0g for 11 ms 


NON·OPERATING 


Temperature 
- 
25°C to 60°C 


Relative 
Humidity 
- 
20% to 80% non-condensing 


Altitude 
- 
Sea level to 40,000 feet 


Vibration 
- 
0.008 
inches 
peak-to-peak, 
5-25 Hz; 


0.004 inches peak-to-peak, 
25-55 Hz; 2.0g O-to-peak, 


55-300 Hz 


Shock - 
15g for 11 ms 


Physical Characteristics 


Width 
- 
16.75 in. (42.55 cm) 
Height 
- 
12.25 in. (31.12 cm) 
Depth - 
21.00 in. (53.34 cm) 
Weight 
- 
75 pounds 
(34.02 kg) 


Extensive System Documentation 


The 
SYSTEM 
86/330A 
is 
shipped 
with 
six 


documentation 
binders 
containing 
over 
28 in- 


depth 
manuals 
on all 
aspects 
of 
hardware 
and 


software 
operation. 
A system 
installation 
and 


maintenance 
manual, 
in addition 
to a system 
over- 


view manual, 
is also included. 


Part Number 
Description 


SYS 86/330AAR 
Kit 
120V 60 Hz 
(North 
American 
Version) 


SYS 86/330ABR 
Kit 
220V 50 Hz 
(European 
Version) 


SYS 86/330ACR 
Kit 
100V 50 Hz 
(Japanese 
Version) 


SYS 86/330A Doc 
Complete 
manual 
set 


inter 


iTPS 86/445 
Transaction 
Processing System 


• A high-performance, 
expandable 
commercial 
microcomputer 
system, 


supporting 
up to 16 users 


• A streamlined 
execution 
environment 
for database 
and 


transaction-oriented 
applications 


• A member 
of the Intel iTPS family 


of compatible 
systems 


• Extensive communications 
capabilities 


including 
3270 SNA, 3270 Bisync 
and 2780/3780 
RJE 


• An "Open 
System" 
designed for 
grow~h to future 
VLSI technology 


• Fully supported 
by Intel's 
worldwide 


support 
and service organization 


The iTPS 86/445 Transaction 
Processing System is a high- 
performance, 
multiuser system 


specifically designed for use in 
commercial transaction 
processing 
environments. It provides mainframe 
calibre capabilities in an economical, 
high-quality package of hardware 
and software. The excellent price- 
performance ratio of the iTPS 
86/445, coupled with the flexibility 
with which it can be configured, 
make it the ideal vehicle for 
delivering cost effective solutions to 
a wide spectrum of commercial 
applications. 


The iTPS 86/445 central system is 
housed in an attractive, table-height, 
free-standing unit. This contains the 
Intel 8086-based central processor, 
up to I megabyte of error corrected 
memory, from 35 to 336MB of disk 
storage, a O.6MB diskette drive, and 
communications 
facilities for from 
1-16 RS-232 terminals and one or 
more host links. Peripherals 
available with the system include 
terminals, a printer, and an 11.7MB 
~-inch magnetic cartridge tape. 


The iTPS software includes a 
powerful multiuser operating 
system, a unique software subsystem 
for developing and executing on-line 
applications, support for all the 
popular higher level languages, and 
a full complement of utilities. 


The iTPS 86/445 is a high end 
member of the Intel iTPS family of 
transaction 
processing systems which 


offers a wider range of storage and 
communications 
capacities than 
other members of the family. Thus 
applications written for the iTPS 
86/445, for example, will run 
without change on the iTPS 86/435 
given equivalent resources. To the 
applications developer, this means 
software can be developed once and 
then be readily ported between large 
and small systems. 


mws 
•. Aun~~meTransa[;~~on 
managemen~ 
2. In~egra\ed Aela\~onal 
[]a~abase 
a. ApPIi[;a\~on 
[]elJeiopmen~ Pa[;lIage 


iTAPS APPLICATION 
ENVIRONMENT 


The iTPS 86/445 can dramatically 
increase programmer productivity 
and streamline application execution 
with a powerful interactive software 
system called iTAPS-the 
Intel 
Terminal Application Processing 
System. iTAPS is a comprehensive 
transaction 
processing and database 
management software system which 
runs as a subsystem on top of the 
iTPS executive. The elements of 
iTAPS include a complete 
transaction 
monitor, an integrated 
relational database manager, an on- 
line database inquiry and update 
facility, an English-like query 
capability, five levels of security, 
and built-in recovery and restart 
mechanisms. 


By providing a non-procedural, 
interactive approach to developing 
applications, 
iTAPS significantly 
reduces the time and effort required 
to design, implement, and maintain 
on-line applications. This allows the 
developer to deliver quality 
applications which are optimized for 
end-user execution performance yet 
can be easily customized for 
individual users' needs. 


Applications are produced using an 
interactive development facility 
which generates internal iTAPS 
tables that define data structures, 
menu interfaces, and transaction 
flow. When the application is 
executed, these tables control how 
built-in iTAPS facilities are invoked 
and how data is accessed. In this 
way, many applications can be 
developed using just the built-in 
facilities provided by iTAPS, while 
more complex or specialized 
applications can be accommodated 
by adding user programs written in 
COBOL and PASCAL to the 
standard iTAPS modules. In 
addition, use of iTAPS ensures that 
the applications developer has the 
freedom to customize applications 
to match individual user 
requirements without having to 
perform major surgery on his 
software. 


In the run-time environment, 
iTAPS' transaction 
processing 


monitor controls the overall 
execution of the application and 
provides multiple levels of access 
control for both programs and data. 
It also furnishes recovery and restart 
facilities to ensure the integrity of 
the content of databases. iTAPS' 
integrated relational database 
manager provides efficient, 
synchronized, shared access to the 
applications information 
and 


supports an English-like casual user 
query and update facility. This 
interactive facility allows casual 
users to access and update databases 
and to create and format their own 
reports using simple, free format 
commands. 


The iTPS 
86/445 
provides 
users 
with a broad 
selection 
of the most 
popular 
programming 
languages 
for 
developing 
commercial 
applications. 


Comprehensive 
support 
is provided 
for ANSI 
74 COBOL, 
ISO 
PASCAL, 
FORTRAN-77, 
BASIC, 
PL/M, 
and a macro 
assembler. 
This 
support 
includes 
extensive 
documentation, 
powerful 
debugging 
tools, 
and a full screen 
editor 
which 
enables 
programmers 
to easily create 
and update 
their 
source 
programs. 
Support 
utilities 
enable 
the user to 
combine 
separately 
compiled/ 


assembled 
programs 
and execute 
them 
as a single entity. 
The iTPS 
high-level 
languages 
are all very 


compatible 
with mainframe 
implementations, 
ensuring 
minimal 
effort 
to convert 
existing 
applications 
onto 
the 86/445. 


The operating 
system 
for the iTPS 
is 
a commercially 
enhanced 
version 
of 
the mature, 
high performance, 
real- 
time iRMX™ 86 executive. 
Known 
as iRMX 
86C, 
it is a comprehensive 
multiuser, 
multiprogramming 
operating 
system 
which 
includes 
the 
capability 
to share 
files and 
programs 
between 
independent 
users. 
It is designed 
for use In a 
wide variety 
of high throughput 
applications, 
especially 
transaction- 
oriented 
processing. 


One of the most 
significant 
features 
of the operating 
system 
is the Re- 
entrant 
Program 
Manager 
(RPM). 
This enables 
multiple 
users to share 
single copies 
of programs, 
and to 
dynamically 
page portions 
of large 
programs 
or data 
sets in and out of 
system 
memory. 
This system 
also 
provides 
SIOS, 
the Shared 
I/O 
System, 
which 
allows 
multiple 
users 
to share 
files. SIOS 
includes 
a 
dynamic 
record-level 
locking 
facility 
to ensure 
data 
integrity 
while 
multiple 
users are concurrently 
accessing 
and updating 
data 
in the 
same 
file. 


iTPS 86/445 
CENTRAL 
SYSTEM 


The iTPS 
86/445 
applications 
processor 
is based 
on the Intel 
8086, 
which 
is by far the world's 
most 
widely 
used 
l6-bit 
microprocessor. 


The powerful 
8086 instruction 
set is 
ideal 
for use in high-performance 
multiprogramming 
environments, 
and has many 
features 
which 
optimize 
the performance 
of higher 
level languages. 
An RS-232C 
remote 
diagnostic 
port 
on the processor 
provides 
a facility 
to exercise 
and 
monitor 
the system 
remotely 
in 
diagnostic 
mode. 
2-36 


As with all of Intel's 
"Open 


Systems," 
the iTPS 
86/445 
uses the 
IEEE-796 
standard 
Multibus, 


ensuring 
that 
future 
VLSI 
can be 


easily 
incorporated 
with the system. 


This also provides 
an easy path 
for 
adding 
custom 
or third-party 


supplied 
Multibus-based 
features 
to 
the system. 
Depending 
on the 


system 
configuration, 
as many 
as 7 
open 
multi bus board 
slots are 


available 
for such extensions. 


The iTPS 
86/445 
central 
system 


includes 
up to one megabyte 
of 


error 
corrected 
main 
memory, 
from 
35 to 336MB 
of Winchester 
disk 


storage, 
and a O.6MB, 
5-inch 


. double-sided 
double-density 
diskette 
drive 
for removable 
storage. 
There 
is also provision 
for an optional 
Y.-inch 
start/stop 
magnetic 
cartridge 
tape 
drive. 
In addition 
to a 


Centronics-compatible 
printer 


interface, 
the base system 
accommodates 
the attachment 
of up 
to four 
terminals 
via an intelligent 
communications 
controller. 


Additional 
controller 
modules 
can 
be added 
to allow 
up to 16 terminals 
to be configured. 


MASS STORAGE DEVICES 


The iTPS 86/445 offers a choice of 
two models of 8-inch Winchester 
disk drives. The high-performance 
84MB capacity drive has an average 
access time of 20 msec and a 
transfer rate of 1.2MB/sec. The 
35MB capacity drive has an average 
access time of 45 msec and a 
transfer rate of 0.8MB/sec. 
A total 


of four drives, of the same type, can 
be supported by the system. 


For archival and back-up purposes, 
the iTPS 86/445 provides an 
optional 
\4-inch magnetic tape 


cartridge drive. This has a formatted 
capacity of 11.7M bytes, a transfer 
rate of 192K bits/sec, and uses a 
removable tape cartridge. 


The iTPS 86/445 provides a 
versatile set of communications 
facilities to support a wide variety 
of distributed processing 
environments. The system supports 
up to 16 E.S-232C communications 
lines, operating in asynchronous 
mode at up to 19.2K bits/sec. For 
communication 
with remote host 


systems, support is offered for 3270 
communications 
emulation in both 
Bisync and SDLC/SNA 
modes; and 
for 2780/3780 (Bisync) 
communications 
emulation. 


Ethernet· 
connection can be 
accomplished by use of the 
iSBC®-551 controller module, and 
the customer can incorporate other 
specialized communications 
interfaces by using the open 
MULTIBUS<!)slots which are 
available in the systems enclosure. 


The iTPS terminal workstation is an 
intelligent, full function, 
ergonomically superior terminal. 
The iTPS terminal is human 
engineered to provide the maximum 
in ease-of-use and efficiency. The 
screen rotates and tilts, and the 
detached keyboard has sculptured 
key caps in a typewriter style layout, 
plus 16 function keys and a 14-key 
numeric pad. A local RS-232C 
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interface enables the customer to 
attach a local printer to the terminal 
for hard copy of screen images. The 
terminal has a full array of 
intelligent features, including full 
cursor addressability, 
full editing, 


protected fields, reverse video, 
blink, and underline. 


The use of silicon software in the 
iTPS terminal distributes the editing 
of iTAPS input data from the iTPS 
central processor down to the local 


device. This microcode can 


significantly enhance the 


performance of the 


iTPS 86/445 for 


iTAPS 
, 
applications by 
offloading the 


editing function 


from the central processor, yet 


does not limit the device's use in 
non-iTAPS mode. The feature also 
enhances operator performance 
by 


notifying the operator of input 
errors as they are entered. 


The iTPS printer is attached to the 
iTPS 86/445 via a Centronics- 
compatible parallel I/O interface. 
This 200-character-per-second 
printer combines quality 
performance with quiet operation 
and excellent reliability. It can print 
both 10 and 16.5 characters/inch, 
handles up to 6-part forms, and has 
vertical spacing of 6 and 8 lines per 
inch. The printer also has excellent 
built-in diagnostics for easy 
maintenance. 


The iTPS System, terminals, and 
printers are fully supported by 
Intel's worldwide Product Service 
organization. 
Initial system 


installation is also performed by 
Intel's trained customer service 
engineers and is included in the 
system's price. 


Word Size 
Instruction-8, 
16 or 32 bits 
Data-8 
or 16 bits 


Instruction Cycle Time 


250 nanoseconds for fastest 
executable instructions (assuming 
instruction is in the queue) 
750 nanoseconds for fastest 
executable instructions (assuming 
instruction is not in the queue) 


Memory Capacity 
RAM-640K 
bytes are supplied 
with the base system, may be 
expanded to one megabyte. All 
memory has ECC. 


Processor and Peripheral Cabinet 
Contains: 5Y." floppy disk drive, 


8" disk drive(s), optional 
Y." 
tape cartridge drive, power 
supplies, fans, MULTIBUS@ 
card cage with up to 7 slots 
available for custom use. 


Dimensions: 29.5" high, 24.5" 
wide, 30" deep 


Processor Interfaces 
Serial-I 
RS-232C from 110to 


19.2K baud, asynchronous 


Parallel-I 
parallel I/O port with 
Centronics printer interface 


Communications 
Serial-16 
RS-232C ports, 


configurable from 110to 19.2 
baud, asynchronous 


BISYNC-2780/3780 
RJE 


emulation 
-3271 
emulation 


SDLC-3274/76 
SNA emulation 


Ethernet: iSBC-550 controller 


Mass Storage 
I-484MB 
Winchester disk drives 


20 msec average access or 1-4 
35MB Winchester disk drives 45 
msec average access 


5V. " floppy disk drive double- 
sided, double-density, 0.6MB 
capacity 


I~ 
" cartridge tape drive, 11.7MB 
formatted capacity 


ENVIRONMENTAL 
REQUIREMENTS 


Operating 
Temperature-15 
·C to 32·C 
Humidity-20% 
to 80% non- 


condensing over the operating 
temperature range, witn a 26·C 
wet bulb temperature limit 
Altitude-Sea 
level to 6000 feet 
Vibration-Less 
than 0.2G @ 3 
to 60Hz 


Non-operating 
Temperature-25·C 
to 60·C 
Humidity-IO% 
to 80% 
(non-condensation) 
Altitude-Less 
than 40,000 feet 
Vibration-Less 
than O.4G @ 3 
to 60Hz-Less 
than 
3G, 
non- 
cyclic during shipping 


12.5A (max) @ 90 to 130 


VAC, 50/60Hz single-phase 
(up to 2 disk drives only) 


9.2A (max) @ 95 to 255 


VAC, 50/60Hz single-phase 


PRODUCT 
SAFETY 
STANDARDS 


The system is listed under UL 
Standard 478 Safety of Electronic 
Data Processing Units and Systems. 
It is also certified by the Canadian 
Standards Association, Standard 
C22.2 154-1975Safety of Data 
Processing Equipment. 
The system 


also conforms to the applicable RFI 
requirements of VDE 871/6.78 class 
A, VDE 875 limit N and FCC rule 
47, CFR part 15 subpart J, 
Emissions Limits for Computing 
Devices. 


11r~ lSO/'I,j~ 
Transaction 


Processing System 


• A major aavancemem 
In Imegraung 


mainframe 
functionality 
with the 


microcomputer 


• A low cost, multiuser desktop 
workstation 


I 


• Another 
member of Intel's iTPS 


family of transaction 
processing 


systems 


• A streamlined 
execution environment 


for database 
and transaction 
applications 


• An "Open 
System" 
for future 
growth to new VLSI 


• Fully supported 
by Intel's worldwide 


support 
and service organization 
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The iTPS 86/435 Transaction 
Processing System brings mainframe 
calibre on-line processing 
capabilities and a highly attractive 
price-performance 
ratio to the small 


business environment. 
It provides a 


high-quality, effective, and 
economical vehicle for delivering 
transaction-oriented 
application 
systems to end user environments. 


The iTPS 86/435 is a desktop 
system designed for efficient 
execution of interactive commercial 
applications. Its hardware includes a 
central processor with 768K bytes of 
memory, a 35MB disk unit, a one 
megabyte diskette, optional 
terminals and printers, and powerful 
application development software. It 
supports one to four users in a 
multiuser, multiprogramming 
environment using a commercially 
augmented version of the 
iRMXT"'86Operating System. 


The iTPS 86/435 is a mid-range 
member of the Intel iTPS family. 
Thus, applications written for other 
members of the iTPS family, e.g., 
the 86/445, will run without change 
on the 86/435 given equivalent 
resources. To the applications 
developer, this means that software 
can be developed once and then be 
readily ported between large and 
small systems. 


iTf1P5 


I i. Runtime Transadion 
management 


2. Integrated 
Relational 
Database 


3. ApPlication 
Development 
Pachage 


iTAPS APPLICATION 
DEVELOPMENT 
PACKAGE 


The iTPS 86/435 increases 
programmer productivity and 
streamlines application execution 
with a powerful software package 
called iTAPS-the 
Intel Terminal 
Application Processing System. 
iTAPS is a comprehensive 
transaction processing and database 
management software system which 
significantly reduces the time and 
effort needed to design, implement, 
and maintain on-line applications. 


iTAPS RUNTIME 
' 


TRANSACTION 
PROCESSING 


The primary objective of iTAPS is 
to deliver applications which are 
optimized for end user execution 
performance. 
It consists of an 
interactive application development 
facility, a high-performance 
transaction monitor with integrated 
relational database manager, and a 
set of built-in modules which 
provide most of the functions 
programmers would normally have 
to write. 


iTAPS is a menu driven system, 
with multiple levels of application 
and file security. It supports an easy 


to use on-line database query and 
update facility, which allows 
unsophisticated 
users to access 


databases and retrieve and format 
their own reports using simple 
English language commands. Full 
database recovery and restart 
facilities are integrated with iTAPS 
to ensure the integrity of all 
application systems. 


The iTPS 86/435 provides users 
with a broad selection of the most 
popular programming languages for 
developing commercial applications. 
Comprehensive support is provided 
for ANSI 74 COBOL, FORTRAN, 
PASCAL, BASIC, PLlM, 
and a 


macro assembler. This support 
includes extensive documentation, 
powerful debugging tools, and full 
screen editor which enables 
programmers to easily create and 
update their source programs. 
Support utilities enable the user to 
combine separately compiled/ 
assembled programs and execute 
them as a single entity. The iTPS 
languages are all highly compatible 
with the mainframe implemen- 
tations, ensuring minimal effort 
in converting existing applications 
onto the 86/435. 


iTPS iRMX™ 86C OPERATING 
SYSTEM 


iRMX 86C is a multiuser, 
multiprogramming 
operating system 
with a shared file system and 
extensive utilities. It is designed for 
use in a wide variety of applications, 
especially transaction-oriented 
processing. iRMX 86C is a 
mainframe calibre executive, with 
many features normally associated 
only with large systems. One of the 
most significant features of the 
operating system is the Re-entrant 
Program Manager (RPM), which 
enables multiple users to share a 
single copy of a program. The 
system also includes SIOS, the 
Shared I/O System, which allows 
multiple users to share files, with 
dynamic record-level locking to 
ensure integrity. 


iTPS 86/435 
CENTRAL 
SYSTEM 


The iTPS 86/435 applications 
processor is based on the Intel 8086, 
which is by far the world's most 
widely used 16-bit microprocessor. 
The powerful 8086 instruction set is 
ideal for use in high-performance 
multiprogramming 
environments, 
and it has many features which 
optimize the performance of higher 
level languages. An RS 232C remote 
diagnostic port on the processor 
provides a facility to exercise and 
monitor the system remotely in 
diagnostic mode. 


As with all of Intel's "Open 
Systems," the iTPS 86/435 uses the 
IEEE-796 standard MULTIBUS@, 
ensuring that future Intel VLSI can 
be easily incorporated with the 
system. This also enables systems 
integrators and others to add 
custom or third-party supplied 
MULTIBUS-based features to the 


system. An open MULTIBUS- 
compatible slot is included in the 
86/435 for this purpose. The iTPS 
86/435 Central System includes 
768KB of main memory, a 35MB 
Winchester disk drive for primary 
on-line storage, and a 1MB 8 inch 
double-sided double-density floppy 
disk for removable storage. In 
addition to a Centronics-compatible 
printer interface, the system 
accommodates the attachment of up 
to four terminals .via an intelligent 
communications controller. 


The iTPS 86/435 supports up to 
four RS 232C communications lines, 
operating in asynchronous mode at 
up to 19.2K bits/sec. In addition, 
the system's open MULTIBUS slot 
can be used by the customer to 
incorporate other communication 
controllers, such as the iSBC@-551 
(Ethernet controller board), which 
allows interconnection with local 
area networks, or the iSBC-88/45, 
which allows interconnection with 
remote networks using 3270 or 3780 
(BISYNC or SOLC). 


The iTPS terminal workstation is a 
very attractive, full function 
ergonomically superior terminal. Up 
to four of these can be attached to 
the iTPS 86/435. The iTPS terminal 
is human engineered to provide the 
maximum in ease-of-use and 
efficiency. The screen rotates and 
tilts, and the detached keyboard has 
sculptured key caps in a typewriter 
style layout, plus 16 function keys 
and a 14-key numeric pad. A local 
RS 232C interface enables a user- 
supplied printer to be attached to 
the terminal for hard copy of screen 
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images. The terminal has a full 
array of intelligent features, 
including full cursor addressability, 
full editing, protected fields, reverse 
video, blink and underline. 


A unique iTAPS feature distributes 
the editing of iTAPS input data to 
the terminal level from the iTPS 
central processor. This local 
microcode can significantly enhance 
the performance of the iTPS 86/435 
for iTAPS applications, and does 


not limit the device's use in non- 
iTAPS mode. 


The iTPS printer can be attached to 
the iTPS 86/435 via a Centronics- 
compatible parallel I/O interface. 
This 200-character-per-second 
printer provides top quality 
performance with quiet operation 
and excellent reliability. It can print 
both 10 and 16.5 characters/inch, 
handles up to 6-part forms, and has 
vertical spacing of 6 and 8 lines per 
inch. The printer has excellent built- 
in diagnostics for easy maintenance. 


The iTPS System, terminals, and 
printers are all fully supported by 
Intel's worldwide Product Service 
organization. 
Initial system 


installation is also performed by 
Intel's trained customer service 
engineers and is included in the 
system's price. 


SPECIFICATIONS 
Word Size 
Instruction- 
8, 16 and 32 bits 
Data- 
8/16 bits 


Instruction Cycle Time 
Fastest executable instructions 
- 
instruction in queue, 400 nanosec 
- 
instruction not in queue, 1.0 
microsec 


Memory Capacity 
768K bytes supplied with system 


Interfaces 
Serial ~ 1 RS 232C from 110 to 
19.2K baud, asynchronous 
Parallel - 
1 parallel I/O port with 


Centronics printer interface 


Communications 
4 RS 232C ports, configurable from 


110 to 19.2K baud, asynchronous 


Mass Storage 
1 8" 35MB Winchester technology 
disk drive 
. 


1 8" 1MB double-sided, double- 


density floppy disk drive 


AC REQUIREMENTS 
5-A at'88 to 126 VAC 60 HZ, single 
phase (U.S.) 
2.5-A at 176 to 252 VAC 50 HZ, 
single phase (Europe) 
5-A at 85 to 110 VAC 60 HZ, single 
phase (Japan) 


Maximum total power consumption 
550W 


PRODUCT SAFETY 
STANDARDS 
The system is listed under UL 
standard 114 Safety of Electronic 
Data Processing Units and Systems. 
It is also certified by the Canadian 
Standards Association, standard 
C22.2 154-1975 Safety of Data 
Processing Equipment. The system 
complies with the International 
Electronics Commission standard 
IEC 435 Safety of Data Processing 
Equipment. The system also 
conforms to the applicable 
RFI/EMI 
requirements for VDE 
0871/6.78 and FCC rule CFR part 
15 subpart J Emission Limits for 
Computing Devices. 


ENVIRONMENTAL 
REQUIREMENTS 
Operating 
Temperature- 
15°C to 35°C 


Relative Humidity- 
20070 to 80070 


non-condensing over the 
operating temperature range· 


Altitude- 
Sea level to 6000 feet 


Vibration- 
LOg @ 10 to 55 HZ 


·Note: The environment 
combination of humidity and 
temperature together cannot exceed 
26°C wet bulb. 


Non-Operating 


Temperature- 
-25 ° to 60°C 


Relative Humidity- 
20070 to 80070 


non-condensing 


Altitude- 
Sea level to 12,000 feet 


Vibration- 
1.0g for 5ms shock 


Single Board 
Computers 
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intel 


• 
IEEE 796 industry 
standard 
system 
bus 


• 
Supports 
multiple 
processor 
systems 
with multi-master 
bus structure 


• 
8-bit and 16-bit devices 
share the same 
MUL TIBUS® system 
resources 


• 
Foundation 
of Intel's 
Total 
System 
Architecture: 
MULTIBUS;'J iLBX,TM 


MULTICHANNEL™ 
and iSBX ™ busses 


• 
16 Mbyte 
addressing 
capability 


• 
Bus bandwidth 
of up to 10 megabytes 


per second 


• Supported 
by a complete 
family of 


single board computers, 
memory, 
digital 


and analog 
I/O, peripheral 
controllers, 


graphics 
and speech 
recognition, 


packaging 
and software 


• Supported 
by over 150 vendors 


providing 
over 1000 compatible 
products 


The MUL TIBUS® System bus is one of a family of standard bus structures resident within Intel's total system architecture. 
The MUL TIBUS interface is a general purpose system bus structure containing 
all the necessary signal lines to allow 


various system components to interact with one another. This device interaction is built upon the master-slave concept. 
The "handshaking" 
between master and slave devices allows modules of different speeds to use the MUL TIBUS interface 


and allows data rates of up to 5 million transfers per second. The MUL TIBUS system bus can support multiple master 
devices (16) on a 18 inch backplane and can directly address up to 16 megabytes of memory. As a non-proprietary, stand- 
ard system bus, the MUL TIBUS interface has become the most prominent 8/16-bit microcomputer system bus in the indus- 
try with over 150 vendors supplying over 1000 MUL TIBUS compatible products. Its success as the industry standard has 
been reinforced by adoption of the MUL TIBUS specification by the Institute of Electrical and Electronic Engineers - 
(IEEE 


796 System Backplane Bus). MUL TIBUS-based systems have been designed into applications, such as, industrial auto- 
mation and control, office systems and word processing, graphics systems and CAD/CAM, telecommunications 
systems 


and distributed 
processing. 


The following 
are trademarks 
of Inlel Corporation 
and may be used only to describe 
lnlel products: 
Intel, 
ICE, 
iMMX, 
iAMX, 
iSSe, 
iSBX, 
iSXM, 
MUl TIBUS, 
Multichannel 
anQ MUL TJMQDUlE 


Inlel Corporation 
assumes 
no responsibility 
for the use 01 any circuitry 
other 
than circuitry 
embodied 
in an lnlel 
product. 
No other 
circuit 
palent 
licenses 
are implied. 
Information 
'-;Qn!air:ed 


herein 
supercedes 
previously 
published 
specifications 
on these 
devices 
from 
Intel. 
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Architectural Overview 


The MUL TIBUS@system bus is the physical framework 
and the conceptual 
foundation 
of Intel's total system ar- 


chitecture. It is a general purpose system bus used in con- 
junction with the single board computer concept to provide 
a flexible mechanism for inter-module processing, control 
and communication. 
The MUL TIBUS interface supports 


modular CPU, memory and 1/0 expansion in flexible, cost 
effective 
microcomputer 
system 
configurations. 
These 


configurations 
implement single board computers and ex- 
pansion 
modules 
in a multiple 
processor 
approach 
to 


enhance 
system 
performance. 
This enhanced 
per1br- 


mance is achieved through partitioning of overall system 
functions 
into tasks that each of several processors can 


handle individually. When new system functions are added 
(peripherals) 
more processing 
power can be applied to 


handle them without impacting existing processor tasks. 


Structural Features 


The MUL TIBUS interface is an asynchronous, 
multipro- 


cessing system bus designed to perform 8-bit and 16-bit 
transfers between single board computers, 
memory and 


1/0 expansion boards. Its interface structure consists of 24 
address lines, 16 data lines, 12 control lines, 9 interrupt 
lines, and 6 bus exchange lines. These signal lines are im- 
plemented 
on single 
board 
computers 
and a mating 


backplane 
in the form of two edge connectors 
resident 
on 6.75" x 12.00" 
form factor PC boards. The primary 
86-pin P1 connector contains all MUL TIBUS signal lines 
except the four address extension 
lines. The auxiliary 
60-pin P2 connector 
contains 
the four MUL TIBUS ad- 
dress extension 
lines, and reserves 
the remaining 
56 
pins for implementing 
the iLBXTM Execution 
Bus into 
the MUL TIBUS system 
architecture. 


Bus Elements 


The 
MUL T1BUS system 
bus supports 
three 
device 
categories: 
1) Master, 2) Slave, 3) Intelligent 
Slave. 


A bus master device is any module which has the ability 
to control the bus. This ability is not limited to only one 
master device. The MUL TIBUS interface 
is capable 
of 
supporting multiple masters on the same system through 
bus exchange 
logic. Once access has been acquired by 


a master device, 
it has a period of exclusive 
control to 
affect data transfers through 
a generation 
of command 
signals, address signals and memory or 1/0 addresses. 


A bus slave device 
is a module 
that decodes 
the ad- 
dress lines on the MUL TIBUS and acts upon the com- 
mand signals from the bus masters. 
Slave devices are 
not capable 
of controlling 
the MUL TIBUS 
interface. 


The intelligent 
slave has the same bus interface 
attri- 
butes as the slave device but also incorporates 
an on- 


board microprocessor 
to control on-board memory and 
1/0 tasks. This combination of on-board processor, mem- 
ory and 1/0 allow the intelligent 
slave to complete 
on- 
board operations 
without 
MUL TIBUS access. 


Bus Interface/Signal 
Line Descriptions 


The MUL TIBUS 
system 
bus signal 
lines are grouped 
into five classes 
based on the functions 
they perform: 
1) control lines, 2) address and inhibit lines, 3) data lines, 
4) interrupt lines, 5) bus exchange 
lines. Figure 2 shows 
the implementation 
of these signal lines. 


The MUL TIBUS control lines are broken down into five 
sub-groups: 
clock signals (2), commands 
(4), acknow- 
ledge (1), initialize (1), and lock (1). The two clock signals 
provide 
for the generation 
of a master 
clock 
for the 
system and the synchronization 
of bus arbitration 
logic. 


The four command 
lines are the communications 
links 
between 
the bus masters 
and bus slaves, 
specifying 
types of operations 
to be performed 
such as reads or 
writes from memory 
or I/O. The transfer 
acknowledge 
line is the slave's 
acknowledgement 
that a requested 


action of the master is complete. 
The initialize signal is 


generated 
to reset the entire system to a known state. 


The lock signal is used by an active bus master to lock 
dual-ported 
for mutual exclusion. 


The address and inhibit lines are made up of 24 address 
lines, two inhibit lines, and one byte control line. The 24 
address lines are signal lines used to carry the address 
of the memory 
location 
or the 1/0 device that is being 


referenced. 
These 24 lines allow a maximum 
of 16 mil- 


lion bytes of memory to be accessed. When addressing 
an 1/0 device, sixteen address lines are used to address 
a maximum 
of 64 thousand 
devices. 
The two inhibit 


lines are used to allow different types of memory (RAM, 
ROM, etc.) having the same memory address to be ac- 
cessed 
in a preferred 
priority 
arrangement. 
The byte 


control 
line is used to select the upper byte of a 16-bit 


word in systems 
incorporating 
16-bit memory 
and I/O 


modules. 


The MUL,TIBUS interface supports sixteen bi-directional 
data lines to transmit 
or receive information 
to or from 


a memory 
location 
or an 1/0 port. 
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The MUL TIBUS interrupt lines consist of eight interrupt 
request lines and one interrupt acknowledge 
line. Inter- 
rupts are requested 
by activating 
one of the eight inter- 


rupt request lines. The interrupt 
acknowledge 
signal is 


generated 
by the bus master when an interrupt request 


is received. 
It effectively 
freezes interrupt status and re- 


quests the placement of the interrupt vector address on- 
to the data lines. There are six bus exchange 
lines that 


support two bus arbitration 
schemes on the MUL TIBUS 


system bus. A bus master gains control of the bus through 
the manipulation 
of these signals. The bus request, bus 


priority, 
bus busy, and bus clock signals 
provide 
for a 


slot dependent 
priority 
scheme 
to resolve bus master 


contention 
on the MUL TIBUS interface. Use of the com- 


mon bus request signal line can save arbitration time by 
providing 
for a higher priority path to gain control of the 


system 
bus. 


Bus Operation Protocol 


DATA TRANSFER 
OPERATION 


The data transfer 
operation 
of the MUL TIBUS system 


bus is a straight-forward 
implementation 
of an asynchro- 


nous master-slave 
handshaking 
protocol. Figures 3 and 


. 4 show the basic timing for a read and write data transfer 


operation. 
A MULTIBUS 
data transfer begins by having 


the bus master place the memory or I/O port address on 
the address 
bus. If the operation 
is a write, the data is 


also placed 
on the data 
lines at this time. 
The bus 
master then generates 
a command 
(I/O read or write, 
or memory read or write) which activates the appropriate 
bus slave. 
The slave accepts 
the data if it is a write 


operation. 
or places data on the data bus if it is a read. 
A transfer 
acknowledge 
is then sent to the bus master 


by the bus slave, allowing 
the bus master to complete 


its cycle, 
removing 
the command 
from the command 
line, and then removing 
the address and data from the 


MUL TIBUS 
interface. 


INTERRUPT 
OPERATIONS 


The MUL TIBUS interface supports two types of interrupt 
implementation 
schemes, 
Non-Bus 
Vectored 
and Bus 


Vectored. 
Non-Bus 
vectored 
interrupts 
are interrupts 


handled 
on the bus master which 
do not require 
the 


MUL TIBUS interface for transfer of the interrupt 
vector 


address. 
The interrupt 
vector address 
is generated 
by 


the interrupt 
controller 
on the master and transfered 
to 


the processor over the local bus when an interrupt request 
line is activated 
by a slave module over the MUL TIBUS 


interface. 
Bus vectored 
interrupts 
are interrupts 
which 


transfer the Interrupt vector address along the MUL TIBUS 
data lines from the slave to the bus master using the in- 
terrupt acknowledge 
command 
signal for synchroniza- 


tion. When 
an interrupt 
request 
occurs, 
the interrupt 


control logic on the bus master interrupts the processor, 
generating 
an interrupt 
acknowledge 
command 
that 
freezes the interrupt 
logic on the bus for priority resolu- 
tion and locks the MUL TIBUS system bus. After the bus 
master selects 
the highest 
priority 
active interrupt 
re- 


quest lines, a set of interrupt 
sequences 
allow the bus 
slave to put its interrupt vector address on the data lines. 
This address is used as a pointer to interrupt the service 
routine. 


The MUL TIBUS system bus can accommodate 
several 
bus masters on the same system, each one taking con- 
trol of the bus as it needs to affect data transfers. 
The 
bus masters request bus control through a bus exchange 
sequence. 


The MULTIBUS interface provides for two bus exchange 
priority 
techniques: 
a serial technique 
and a parallel 
technique. 
In a serially arbitrated 
MUL TIBUS system, 


requests for system bus access are ordered 
by priority 
on the basis of bus slot location. Each master on the bus 
notifies the next lower priority 
master when it needs to 
use the bus, and it monitors 
the bus request status of 


the next higher priority-master. 
Thus, the masters pass 


bus requests along from one to the next in a daisy chain 
fashion. The parallel bus arbitration 
technique 
resolves 


system bus master priorities using external hardware in 
the form of a priority resolution circuit. This parallel arbi- 
tration logic is included 
in many commercially 
available 


cardcages. 


Mechanical Implementation 


BUS PIN ASSIGNMENTS 


Printed circuit boards (6.75" x 12.00") designed to inter- 
face to the MUL TIBUS system bus have two connectors 
which plug into the bus backplane. 
These connectors, 


the 86-pin P1 (Primary) 
and the 60-pin P2 (Auxiliary), 


have specific 
pin/signal 
assignments. 
Because of this, 


the designer must insure that the MUL TIBUS backplane 
being designed is compatible 
(pin-for-pin) with these two 


connectors. 
Tables 1 and 2 show the pin/signal 
assign- 


ments for the P1 and P2 edge connectors. The MULTIBUS 
interface 
connection 
is accomplished 
via a rigid back- 


plane that has connectors that mate to the P1 (43/86-pin) 
board edge connector 
and allows for connectors 
that 
mate to the P2 (30/60-pin) board edge connector. 
Figure 


5 shows a typical 
MUL TIBUS backplane. 
Figure 6 dis- 


plays the connector and pin numbering 
convention. 
Fig- 
ure 7 shows the standard MULTIBUS form-factor printed 
wiring 
board outline. 


Please refer to Intel's MULTIBUS specification 
and iLBX 


bus specification 
for more detailed 
information. 


Pin 
(Component Side) 
Pin 
(Circuit Side) 


Mnemonic 
Description 
Mnemonic 
Description 


Power 
1 
GND 
Signal GND 
2 
GND 
Signal GND 
Supplies 
3 
+5V 
+5Vdc 
4 
+5V 
+5Vdc 
5 
+5V 
+5Vdc 
6 
+5V 
+5Vdc 
7 
+12V 
+12Vdc 
8 
+12V 
+12Vdc 
9 
Reserved, bussed 
10 
Reserved, bussed 
11 
GND 
Signal GND 
12 
GND 
Signal GND 


'Bus 
13 
BCLK* 
Bus Clock 
14 
INIT* 
Initialize 


Controls 
15 
BPRN* 
Bus Pri. In 
16 
BPRO* 
Bus Pri. Out 
17 
BUSY* 
Bus Busy 
18 
BREQ* 
Bus Request 


19 
MRDC-lC- 
Mem Read Cmd 
20 
MWTC* 
Mem Write Cmd 


21 
IORC* 
110 Read Cmd 
22 
IOWC* 
110 Write Cmd 
23 
XACK* 
XFER Acknowledge 
24 
INH1* 
Inhibit 1 (disable RAM) 


Bus 
25 
LOCK* 
Lock 
26 
INH2* 
Inhibit 2 (disable PROM or ROM) 


Controls 
27 
BHEN* 
Byte High Enable 
28 
ADIO* 


and 
29 
CBRQ-lC- 
Common Bus Request 
30 
AD11* 
Address 


Address 
31 
CCLK* 
Constant Clk 
32 
AD12* 
Bus 


33 
INTA* 
Intr Acknowledge 
34 
ADI3* 


Interrupts 
35 
INT6* 
Parallel 
36 
INT7* 
Parallel 


37 
INT4* 
Interrupt 
38 
INT5* 
Interrupt 
39 
INT2* 
Requests 
40 
INT3* 
Requests 
41 
INTO* 
42 
INTI * 


I 


Address 
43 
ADRE* 
44 
ADRF* 
45 
ADRC* 
46 
ADRD* 
- 


47 
ADRA* 
Address 
48 
ADRB* 
Address 
49 
ADR8* 
Bus 
50 
ADR9 * 
Bus 


51 
ADR6* 
52 
ADR7 * 


53 
ADR4* 
54 
ADR5 * 
55 
ADR2* 
56 
ADR3 * 


57 
ADRO* 
58 
ADR1* 


Data 
59 
Dt\TE* 
60 
DATF* 
61 
DATC* 
62 
DATD* 
63 
DATA* 
Data 
64 
DATB* 
Data 
65 
DAT8* 
Bus 
66 
DAT9 i, 
Bus 
67 
DAT6* 
68 
DAT7 * 


69 
DAT4* 
70 
DAT5 * 
71 
DAT2* 
72 
DAT3 i, 


73 
DATO* 
74 
DATI * 


Power 
75 
GND 
Signal GND 
76 
GND 
Signal GND 


Supplies 
77 
Reserved, bussed 
78 
Reserved, bussed 
79 
-12V 
-12Vdc 
80 
-12V 
-12Vdc 
81 
+5V 
+5Vdc 
82 
+5V 
+5Vdc 
83 
+5V 
+5Vdc 
84 
+5V 
+5Vdc 
85 
GND 
Signal?ND 
86 
GND 
Signal GND 


All Reserved pins are reserved for future use and should not be used if upwards 


compatibility 
is desired . 


•Note:The Reserved MULTIBUSP2 connector 
pin/signalassign- 
ments are contained in Intel's iLBXBus Specification. 


(Component 
Side) 
Pin 
(Circuit 
Side) 
Pin 


Mnemonic 
Description 
Mnemonic 
Description 


I 
Reserved 
2 
Reserved 


;1 
Reserved 
4 
Reserved 


;; 
Reserved 
6 
Reserved 


7 
Reserved 
H 
Reserved 


9 
Reserved 
10 
Reserved 


II 
Reserved 
12 
Reserved 
1:3 
Reserved 
14 
Reserved 
I;; 
Reserved 
16 
Reserved 
17 
Reserved 
IH 
Reserved 


19 
Reserved 
:W 
Reserved 


21 
Reserved 
22 
Reserved 


2:3 
Reserved 
24 
Reserved 


2;; 
Reserved 
26 
Reserved 
27 
Reserved 
2H 
Reserved 


29 
Reserved 
:10 
Reserved 
31 
Reserved 
:12 
Reserved 
:33 
Reserved 
:14 
Reserved 
:3;; 
Reserved 
:16 
Reserved 


;J7 
Reserved 
:IH 
Reserved 


:J9 
Reserved 
40 
Reserved 


41 
Reserved 
42 
Reserved 


43 
Reserved 
44 
Reserved 


4;; 
Reserved 
46 
Reserved 
47 
Reserved 
4H 
Reserved 


49 
Reserved 
,,0 
Reserved 
;;1 
Reserved 
;iz 
Reserved 


53 
Reserved 
;";4 
Reserved 


Address 
;;ii 
ADRI6· 
Address 
Rus 
;"i6 
AllRI7. 
Address 
Rus 


;;7 
ADRI4· 
iiH 
AllRl"· 


;;9 
Reserved. 
Russed 
60 
Reserved. 
Russed 


•Note: The Reserved MULTIBUS P2 connector pin/signal assign- 
ments are contained in Intel's iLBX ,BUSSpecification. 


Bus Devices Supported 


16 total 
devices 
- 
(Master, 
Slave, Intelligent 
Slave) 
Word Size 


Data - 
8 and 16-bit 


110Addressing 


16·blts 
- 
64 Kbytes 


Bus Bandwidth 


10 megabytes/see 
- 
16-bit 


5 megabytes/see 
- 
8-bit 


Memory Addressing 


24·bits 
- 
16 megabyte 
- direct access 


Maximum Bus Backplane Length 


18 inches 


Bus Exchange Cycle 


200 nsec - Best Case; 300 nsec - Worst Case (assum- 
ing no bus master is currently 
active on the bus.) 


Table 3. 


Standardl 


Parameter 
Ground 
+5 
+12 
-12 


Mnemonic 
GND 
+5V 
+12V 
-12V 


Bus Pins 
P1·1.2.11.12. 
P1·3,4.5.6. 
P1·7.8 
P1·79,80 


75,76,85,86 
81.82.83. 
84 


Tolerance 
Ref. 
±1% 
±1% 
±1% 


Combined 
Line & Load Reg 
Ref. 
0.1% 
0.1% 
0.1% 


Ripple (Peak to Peak) 
Ref. 
50mV 
50mV 
50mV 


Transient 
Response 
100 p.S 
100 p.S 
100 I's 


(50% Load Change) 


IPoint 
of measurement 
is at connection 
point 
between 
motherboard 
and 
power 
supply. 
At any 
card 
edge 
con· 
nector 
a degradation 
of 2% maximum 
le.g. voltage 
tolerance 
±2%1 is allowed. 


ADDRESS 
SETUP 
TIME: 
50 NANOSECONDS 
MINIMUM. 


TIME 
REOUIRED 
FOR SLAVE 
TO GET DATA 
ONTO 
BUS IN ACCORDANCE 
WITH 
SETUP 
TIME 
REOUIREMENT. 
XACK* 
CAN 
BE ASSERTED 
AS SOON 
AS 
DATA 
IS ON BUS. 


TIME 
REQUIRED 
FOR MASTER 
TO IIEMOVE 
CO_AND. 


ADDRESS 
AND 
DATA 
HOLD 
TIME; 
50 NANOSECONDS 
MINIMUM. 


XACK* 
AND 
DATA 
MUST 
BI! REMOVED 
FROM THE BUS A MAXIMUM 
OF 
15 NANOSECONDS 
AFTER 
THE 
COMMAND 
IS REMOVED. 


inter 


1 
ADDRESS 
AND 
DATA 
SETUP; 
50 NANOSECONDS 
MINIMUM. 


2 
TIME 
REQUIRED 
FOR SLAVE 
TO ACCEPT 
DATA. 


3 
TIME 
REQUIRED 
FOR MASTER 
TO REMOVE 
COMMAND 
FROM 
BUS. 


4 
ADDRESS 
AND 
DATA 
HOLD 
TIME; 
50 NANOSECONDS 
MINIMUM. 


5 
XACK* 
MUST 
BE OFF THE BUS 65 NANOSECONDS 
AFTER 
COMMAND. 
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PARTS 
LIST 


1 PWS TERMINATION 
BACKPLANE 
27 POST WAFER 
CONNECTORS 
(.156" 
PIN CENTERS) 
(J6 AND JI) 
4 EDGE 
SOARD 
CONNECTORS. 
43/86 PINS ON .156" 
CENTERS 
(J2-J5) 
12 WIRE WRAP 
POSTS 
410 
PIN. 2.2K.1I 
RES. 1.5W RESISTOR 
PACKS 
(RP1-RP4) 
110 PIN. lK,1I 
RES. 1.5W RESISTOR 
PACK 
(RP5) 
110PI 
••.• l.1K.1I 
RES. 1.5WRESISTOR 
PACK 
(RPI) 
11K 
REzoISTOR,l/IW. 
%5% (Rl) 
12.2K 
RESISTOR. 
l/IW. 
%% (R5) 
222012 RESISTORS. 
1/4W, %5%IRII' 
Rll) 
233012 RESISTORS. 
1I4W. 
%5% 
Rl0, 
R12) 
251012 RESISTORS. 
l/IW. 
%5% 
R7. RI) 


J1 
J2 


(A POSSIBLE 
CONNECTOR 
CONFIGURATION) 
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LiILffiJ~ 
-HP'CAe 
["'Il+t 
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II Of 
Centers 
Connector 
Vendor 
Vendor 
II 
Intel II 
Function 
Pins 
Inches 
Type 


Multibus 
Connector 
43/86 
0.156 
Soldered' 
VIKING 
2KH43/9AMK12 
(Pl) 
ELFAB 
BS1562D43PBB 
102247-001 


ELFAB 
BW1562D43PBB 
102248-001 
Multibus 
ELDAC 
3370860540201 


Connector 
43/86 
0.156 
Wire wrap'" 
ELFAB 
BW1562A43PBB 
102273-00 1' 


(P1) 
EDAC 
337086540202 


Auxiliary 


Connector 
30/60 
0.1 
Soldered' 
ELFAB 
BS1020A30PBB 
102238-001 
(P2) 
EDAC 
345060524802 


TI 
H421121-30 
N/A' 
Auxiliary 
VIKING 
3KH30/9JNK 


Connector 
30/60 
0.1 
Wire wrap'" 
EDAC 
345060540201 
10224HXJ1 
(P2) 
ELFAB 
BW1020D30PBB 


Notes: 


1. Connector 
heights 
are not guaranteed 
to conform 
to Intel packaging 
equipment. 


2. Wirewrap 
pin lengths 
are not guaranteed 
to conform 
to Intel packaging 
equipment. 
3. 
With 
mounting 
ears 
with 
.128 
mounting 
holes. 


Reference Manuals 


210883 - 
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Operating 
Temperature 
- 
0 to 55°C; 
free 
moving 
air 


across 
modules 
and 
bus 


Humidity 
- 
90% 
maximum 
(no 
condensation) 


• High speed 8- or 16-bit block transfers 


between memory and/or I/O 


• Transfer rates up to 8 megabytes/sec. 


• Full speed operation at distances of up 


to 15 meters. 


• Supports Supervisor, Controller, or 


basic Talker/Listener 
capabilities 


• Off-loads burst mode I/O activities 


from host CPU and MULTIBUS® system 
bus 


• Up to 16 devices may be interfaced to 


the bus. 


• 16 megabytes of memory and 16 


megabytes of I/O are addressable on 
each device 


The MULTICHANNEl!M 
110 Bus is one of a family of standard 
bus structures 
resident 
within 
Intel's 
total system 
architecture. 
The MULTICHANNEL 
bus is a general 
purpose, 
high-speed 
110 bus capable 
of significantly 
increas- 
ing system performance 
by providing 
a separate 
data path for DMA 110 activities. 
By isolating 
110 transfers 
from the 
system bus, the MULTICHANNEL 
bus off-loads 
110 activity from the host CPU, reduces the probability 
of bus satura- 


tion on the system bus, and reduces contention 
between 
110 and data processing 
activities 
on the system bus. The 
MULTICHANNEL 
bus can support 
up to 16 devices at distances 
up to 15 meters with a maximum 
burst throughput 
of 8 megabytes 
per second. These 16 devices are classified in a manner similar to the IEEE 488 bus concept: Super- 
visors, Controllers, 
or Talker and Listeners. 
As a non-proprietary, 
standardized 
110 bus, the MULTICHANNEL 
bus 
is a cost-effective 
DMA interface 
ideal for applications 
such as computer 
graphics, 
specialized 
peripheral 
control, 


automatic 
test equipment, 
video camera image processing, 
data acquisition, 
and high-speed 
MULTIBUS® system- 
to-system 
communication. 
. 


The following 
are trademarks 
of Intel Corporation 
and may be used only 10 describe 
tntel products: 
Intel, 
ICE, iMMX, 
iRMX, 
iSBC, 
iSBX, 
iSXM, 
MUL TIBUS, 
Multichannel 
and MUL TIMOOUlE. 


Intel 
Corporation 
assumes 
no responsibility 
for the use of any circuitry 
other 
than 
circuitry 
embodied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are implied. 
Information 
contained 


herein 
supercedes 
prl'tviously 
published 
specifications 
on these 
devices 
from 
Intel. 
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Architectural Overview 


The MULTICHANNEL 
bus is the standard 
high speed 


I/O interface to MUL TIBUS-based 
systems. 
Its general 


purpose design and high performance 
(8 MB/sec) aug- 


ment the overall system design by improving 
I/O inter- 
face flexibility 
and system throughput. 
The flexibility 
is 


realized 
by using an easy-to-use 
public standard 
inter- 


face that can support up to sixteen 8-bit or 16-bit devices 
at up to 15 meters. 
This structure 
allows the MUL TI- 


CHANNEL 
bus to provide easy 110 system expansion, 
effective 
box-to-box communication, 
and a growth path 


capable of supporting 
new generations 
of high-perform- 


ance I/O devices. The MULTICHANNEL 
bus increases 


system 
throughput 
by providing 
a high-performance 


data path for efficient 
movement 
of large amounts 
of 


data. 


MULTICHANNEL:M 
BUS CONFIGURATION 


The MULTICHANNEL 
bus is a multiplexed, 
asynchro- 


nous block transfer, 
16-bit I/O bus designed 
to handle 


8-bit and 16-bit transfers between peripherals and single 
board computers. 
Its structure (pictured in Figure 2) con- 


sists of 16 address/data 
lines, 6 control lines, 2 interrupt 


lines, plus parity and reset. These signal lines are imple- 


mented as either a 60 conductor 
flat ribbon cable or a 


twisted-pair 
cable 
spanning 
a distance 
of up to 15 


meters. A 30/60-pin 3MI!>connector 
is recommended 
for 


device 
connection 
to the MULTICHANNEL 
bus. The 


male connectors are installed on each MULTICHANNEL 
device and the female connectors 
are mounted 
on the 


cable. To insure system integrity, the MULTICHANNEL 
cable is terminated 
at both ends. 


BUS ELEMENTS 


Three device types - 
the Basic device, 
the bus Con- 


troller device, 
and the bus Supervisor 
device - 
each 


provide a different 
level of capability. 
The Basic Talker/ 


Listener device has lowest capability, 
responding 
only 


to data transfer requests issued by a Superviser 
or Con- 
troller. The bus Controller 
device has higher capability 


than a Basic Talker/Listener 
on the bus. It can respond 


to data transfer requests, control data transfers, and can 
program 
other MULTICHANNEL 
devices 
under direc- 


tion from a bus Supervisor. 
Operating 
at the highest 


capability is the bus Supervisor device. It provides major 
control and management 
of the MULTICHANNEL 
bus. 


The bus Supervisor resolves and grants MULTICHANNEL 
bus priority, 
monitors 
bus status, 
handles 
interrupts, 


and controls the reset line, in addition 
to performing 
all 


bus Controller 
functions. 


infel 


MULTICHANNEL 
bus devices are functionally 
flexible, 


creating 
overlaps 
between 
types of bus functions 
and 
types of bus devices performing 
those functions. These 
devices perform funotions in various states of operation: 
master, slave, talker, listener. When a device is control- 
ling the command/action 
lines, it is in the master state, 
and both the bus Supervisor 
and the bus Controller 
can 
operate in this state, although 
not simultaneously. 
The 
slave state indicates a device that can monitor the com- 
mand/action 
lines. Only Controllers 
and Basic Talker/ 


Listeners 
operate as slaves. All three device types can 


operate 
in the talker state or the listener state, but not 


all at the same time. A Talker is any device selected 
by 


the bus master which is writing data to the bus. A Listener 
is any selected 
device which 
is reading 
data from the 
bus. 


BUS INTERFACE/SIGNAL 
LINE DESCRIPTIONS 


The MULTICHANNEL 
bus signal lines are grouped into 


five classes 
based on the functions 
they perform: 
ad- 
dress/data, 
control, interrupt, 
parity, and reset. The 16 


address/data 
lines are multiplexed 
by a control 
line to 


act either as 16 unidirectional 
address lines or 16 bidi- 
rectional 
data lines. When used as address lines, they 
transmit 
the device address to all devices 
attached 
to 


the MULTICHANNEL 
bus. When used as bidirectional 


data lines, they transmit 
and receive 
data to or from 


MULTICHANNEL 
devices. 
The six control 
lines deter- 


mine the overall operation of the bus from specifying the 
type of data transfer to providing the handshake for data 
transfers between MULTICHANNEL 
devices. Two inter- 


rupt lines are supplied 
to initiate 
and terminate 
data 


transfers, 
and to indicate 
device failures, 
memory fail- 


ures, or parity errors. A parity line and a reset line pro- 
vide support for a parity option and system reset capa- 
bility whenever 
required. 


For proper MULTICHANNEL 
implementation, 
a 60 con- 


ductor (twisted 
pair or flat) cable using a 30/60 pin 3M 


connector, 
is used for device connection 
to the bus. Fig- 


ure 3 is an outline drawing of the iSBC® MULTICHANNEL 
connector 
which 
also shows the pin numbering. 
The 


MULTICHANNEL 
bus connector signal pin assignments 


are listed in Table 1. Cable termination 
is implemented 


at both cable ends to insure proper system integrity over 
a 15-meter cable. Figure 4 is a schematic 
of the cable 


termination 
circuits. 
A cable termination 
module could 


be created 
that would then be connected 
to the cable 


end via a 30/60 pin connector. 


SOLDER 
SIDE 
----- 


~ 
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Lower Row 
Upper Row 


Pin 
Mnemonic 
Signal Name 
Pin 
Mnemonic 
Signal Name 


1 
GND 
GROUND 
2 
ADO! 
ADDRESS 
DATA LINE 0 


3 
GND 
GROUND 
4 
ADlI 
ADDRESS 
DATA LINE 
1 


5 
GND 
GROUND 
6 
AD2! 
ADDRESS 
DATA LINE 2 


7 
GND 
GROUND 
8 
AD3! 
ADDRESS 
DATA LINE 3 


9 
GND 
GROUND 
10 
AD4! 
ADDRESS 
DATA LINE 4 


11 
GND 
GROUND 
12 
AD5! 
ADDRESS 
DATA LINE 5 


13 
GND 
GROUND 
14 
AD6! 
ADDRESS 
DATA LINE 6 


15 
GND 
GROUND 
16 
AD7! 
ADDRESS 
DATA LINE 7 


17 
GND 
GROUND 
18 
AD8! 
ADDRESS 
DATA LINE 8 


19 
GND 
GROUND 
20 
AD9! 
ADDRESS 
DATA LINE 9 


21 
GND 
GROUND 
22 
ADAI 
ADDRESS 
DATA LINE 
10 


23 
GND 
GROUND 
24 
ADB! 
ADDRESS 
DATA LINE 
11 


25 
GND 
GROUND 
26 
ADC! 
ADDRESS 
DATA LINE 
12 


27 
GND 
GROUND 
28 
ADD! 
ADDRESS 
DATA LINE 
13 


29 
GND 
GROUND 
30 
ADE! 
ADDRESS 
DATA LINE 
14 


31 
GND 
GROUND 
32 
ADF! 
ADDRESS 
DATA LINE 
15 


33 
GND 
GROUND 
34 
RESET! 
RESET 


35 
GND 
GROUND 
36 
AACC 
ADDRESS 
MODE 
ACCEPT 


37 
GND 
GROUND 
38 
SRQ! 
SERVICE 
REQUEST 


39 
GND 
GROUND 
40 
STO! 
SUPERVISOR 
TAKE OVER 


41 
GND 
GROUND 
42 
DACC! 
DATA MODE 
ACCEPT 


43 
GND 
GROUND 
44 
SAI 
SUPERVISOR 
ACTIVE 


45 
PB·! 
PARITY 
BIT (INV.) 
46 
PB! 
PARITY 
BIT 


47 
RIW! 
READ 
NOT WRITE 
(INV.) 
48 
RIW 
READ 
NOT WRITE 


49 
AID! 
ADDRESS 
NOT DATA (INV.) 
50 
A!D 
ADDRESS 
NOT 
DATA 


51 
DRDY·! 
DATA READY 
(INV.) 
52 
DRDY! 
DATA READY 


53 
RES 
RESERVED 
54 
RES 
RESERVED 


55 
RES 
RESERVED 
56 
RES 
RESERVED 


57 
RES 
RESERVED 
58 
RES 
RESERVED 


59 
RES 
RESERVED 
60 
RES 
RESERVED 


inter 
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Bus Operation Protocol 
/ 


DATA TRANSFER 
OPERATION 


There are three modes of communication 
in the opera- 


tion protocol: 
address 
mode, 'data mode, and control 
transfer mode. Using these transfer modes, each MULTI- 
CHANNEL 
device provides 
handshaking 
capability 
for 


totally 
asynchronous 
block 
data 
transfers. 
Address 
mode is the time when the address/data 
control 
line is 
high. Information placed on the address/data 
lines of the 
MULTICHANNEL 
bus as two successive 
16-bit words 


,,, 
_____ J 


.-----, 
III 


I, 
I 
___ J 


----I, 
I, 


III 
___ 
I 


is interpreted 
to select or deselect 
a device on the bus 


and address the specific 
resource 
on the device. Typi- 
cally, these address mode transfers 
are only 2 word se- 
quences. 
Figure 5 is a timing diagram of the handshake 
routine 
in address 
mode. The data mode is the time 
when the address/data 
control line is low. Valid data is 
placed 
on the address/data 
lines of the bus and CCln 
occur only after an address mode has been performed. 
Transfers during data mode are usually large quantities 
of either 8- or 16-bit data, and are passed to or from the 
addressed 
device until it is deselected. 
Figure 6 is a tim- 
ing diagram 
of a data transfer 
sequence. 


It 
_ 


MASTER 
WRITING 
1ST ADDRESS 


,,,L__ 


MASTER 
WRITING 
2ND ADDRESS 


DATA 
OR 
ADDRESS 


ADIII-AOFI 


AID 
~---\ 


Riw 


ORDYI 
! 
•__ 1 


---I, 
AACC 
, 
I 


I 
OACCI 
I 
.__ .: 


r----- 


II 


Control transfer 
mode is the time when the bus Super- 
visor selects the bus Controller 
and programs 
its regis- 
ters with required information. 
Once programmed, 
a bus 
Controller 
may select 
a device 
and originate 
a data 
transfer 
operation. 


The operational 
sequences 
of these transfer modes are 
similar in handling read and write operations to and from 
the 16 megabytes 
of memory and the 16 megabytes 
of 
registers addressable on each MULTICHANNEL 
device. 


A typical 
transfer 
sequence 
begins 
when the master 
sends a two-word address sequence 
to select a MULTI- 
CHANNEL 
device 
and specify 
address, 
direction 
and 
resource 
(memory vs. I/O) of the data transfer. 
Follow- 
ing device 
selection, 
the Talker 
proceeds 
to send the 
data as a continuous 
8 or 16-bit data word stream until 
the block data move is complete. The master terminates 
the transfer 
by issuing 
another 
two-word 
address 
se- 
quence 
for device deselection. 


The transfer 
sequence 
described 
is identical 
for both 
memory and register type transfers. The master controls 
similar read and write operations 
between devices, and 
the address select and deselect sequences use the same 
address format. Figure 7 contains the MULTICHANNEL 
bus address 
format. 


DEVICE 
REGISTER 
DEFINITION 


Of the 16 megabytes 
of register 
space per device, the 
first 16 registers 
are pre-defined 
to provide a standard 
register 
area common 
to all devices. 
The remaining 
registers are user definable. 
Table 2 lists the 16 defined 
registers along with their function. The use of this regis- 
ter concept 
allows for standard 
interface 
between 
all 
MULTICHANNEL 
devices. 
Please refer to the MULTI- 


CHANNEL Bus Specification for more detailed information. 


Table 
2. 
MULTICHANNELT" 
Device 
Register 


Definitions 


Register 
Definition 
Mode 
Number 


0 
STO/ Flag/Status 
Read Only 


1 
SRQ/ Flag/Status 
Read Only 


2 
SRQ/ Mask 
Write Only 


3 
Device Command 
Write Only 


4 
Device Parameter 
Write Only 


5 
Data Address 1 
Read or Write 


6 
Data Address 2 
Read or Write 


7 
Block Length 1 
Read or Write 


8 
Block Length 2 
Read or Write 


9 
Error Address 1 
Read Only 


10 
Error Address 2 
Read Only 


11 
Address Extension 
Write Only 


12-15 
Reserved 


16-16 Mby1e 
User Defined 
Read or Write 


BUS INTERRUPT 
HANDLING 


The MULTICHANNEL 
bus Supervisor, 
being respon- 


sible for bus access and control, 
monitors 
the two bus 


interrupt lines. The Supervisor Take-over 
interrupt (STO) 


is used to inform the bus Supervisor that a device wants 
to return control of the bus to the Supervisor 
or that an 


error has occurred. The Service Request Interrupt (SRO) 
is used by devices which do not have control of the bus, 
but require service from the bus Supervisor. 
To locate 


a device transmitting 
a bus interrupt, the bus Supervisor 


WHERE: 


ADDRESS 
(BITS 16-24) = MOST SIGNIFICANT 
BYTE OF 24 BIT MEMORY OR REGISTER 
ADDRESS. 


DEVICE NUMBER 
= A DEVICE NUMBER 
FROM 0 TO 15. 


RES = RESERVED 
BIT. 


M/R = MEMORY/REGISTER 
ADDRESS. 
RiW = READ/WRITE 
BIT. 


ADDRESS 
(BITS 8-15) = MIDDLE BYTE OF 24 BIT MEMORY 
OR REGISTER 
ADDRESS. 
ADDRESS 
(BITS 0-7) = LEASE SIGNIFICANT 
BYTE OF 24 BIT MEMORY OR REGISTER 
ADDRESS . 


• = THESE BITS ARE UNDEFINED 
WHEN 8-BIT ADDRESSING 
IS USED. 


inter 


polls each device attached to the bus by reading the ap- 
propriate 
register of each device and testing for a non- 
zero value. In current implementations, 
the Supervisor 
polls each device only once. 
If the interrupt 
is not re- 
moved an error occurs. 


PARITY 
AND RESET 


Parity operation 
on the MULTICHANNEL 
bus is pro- 
vided, but is not required. 
The bus Supervisor 
selects 


between 
parity mode and non-parity 
mode depending 
upon system requirements. 
If parity mode is selected all 
Talkers 
must generate 
odd parity. All active Listeners 
monitor the parity line and generate 
an STO interrupt 
signal if there is a parity error. 


A reset function is also supported by the MULTICHANNEL 
bus, and is controlled 
by the bus Supervisor 
to bring the 
bus to a known state. It is used to reset all devices after 
power-up, and when required to gain control of the bus. 


Word Size 


Data - 
8, 16-bit 


Memory Addressing 


24-bits 
- 
16 megabyte 
- direct 
access 
- automatic 
incrementing 


Register Addressing 


24-bits 
- 
16 megabyte 
- direct access 


Electrical Characteristics 


DC SPECIFICATIONS 


Maximum Bus Length 


15 meters (50 feet) 


Bus Devices Supported 


16 total devices 
- 
(Supervisor, 
Controller, 
and Talkerl 
Listener) 


Bus Bandwidth 


8 megabytes/sec. 
- 
16-bit 


4 megabytes/sec. 
- 
8-bit 


Signal 
Driver 
Termination 
Min. Driver 
Requirements 
Max. Receiver 
Requirements 


Name 
Type 
(see Note) 
High 
Low 
Load Cap 
High 
Low 
Load Cap 


AD15-0/ 
TRI-STATE 
110 Ohms 
- 
5 ma 
48 ma 
300 pI 
0.2 ma 
0.8 ma 
15 pI 


SAI 
OPEN 
COll 
110/220 
Ohms 
N.A. 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


RESET/ 
OPEN 
COll 
110/220 
Ohms 
NA 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


AACC 
OPEN 
COll 
1K12K Ohms 
N.A. 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


DACC/ 
OPEN 
COll 
110/220 
Ohms 
NA 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


SRQ/ 
OPEN 
COll 
110/220 
Ohms 
NA 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


STO/ 
OPEN 
COll 
110/220 
Ohms 
N.A. 
48 ma 
300 pI 
0.4 ma 
0.6 ma 
15 pI 


RIW 
DIF, NON-INV 
220/470 
Ohms 
-20 
ma 
40 ma 
300 pI 
0.5 ma 
0.5 ma 
15 pI 


RIW/ 
DIF,INV 
470/220 
Ohms 
-20 
ma 
40 ma 
300 pI 
0.5 ma 
0.5 ma 
15 pI 


AID 
DIF, NON-INV 
220/470 
Ohms 
-20 
ma 
40 ma 
300 pI 
0.5 ma 
0.5 ma 
15 pI 


A/D/ 
DIF,INV 
470/220 
Ohms 
-20 
ma 
40 ma 
300 pI 
0.5 ma 
0.5 ma 
15 pI 


PSI 
DfF, NON-INV 
220/470 
Ohms 
-20 
ma 
40 ma 
N.A. 
0.5 ma 
0.5 ma 
N.A. 


PS·/ 
DIF,INV 
470/220 
Ohms 
-20 
ma 
40 ma 
N.A. 
0.5 ma 
0.5 ma 
N.A. 


DRDY/ 
DIF, NON-INV 
220/470 
Ohms 
-20 
ma 
40 ma 
NA 
0.5 ma 
0.5 ma 
N.A. 


DRDY·/ 
DIF,INV 
470/220 
Ohms 
-20 
ma 
40 ma 
N.A. 
0.5 ma 
0.5 ma 
N.A. 


NOTE: 
Termination 
provided only at the physically ends of the interconnect cable. Where the positive termination (pull-up) resistance is 
different from the negative termination (pull-down) resistance, the positive termination resistance is listed first. 
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SUPERVISOR 
SUPERVISOR 
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DEVICE 
DEVICE REGISTERS 
REGISTER 


Figure,g. 
Supervisor 
Interrupt 
Timing 
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Cables and Connectors 


Table 3. 
Cable and Receptacle 
Vendors 


MUlTICHANNEL:M 
Bus Compatible 
Cable 


Vendor 
Ribbon 
Vendor 
No. 
Conduc- 
Type 
tor 


Belden 
Plain Flat 
9L28060 
60 


Belden 
Twisted-Pair 
9V28060 
60 


Belden 
Insulated Flat 
9L28260 
60 


Spectrastrip 
Plain Flat 
455-240-60 
60 


Spectrastrip 
Twisted-Pair 
455-248-60 
60 


Spectrastrip 
Insulated Flat 
151-2830-060 
60 


MUlTiCHANNEL:M 
Bus Compatible 
Receptacles 


Vendor 
Type 
Vendor No. 
Pins 


Berg 
Male 
65823-103 
60 


Berg 
Female 
65949-960 
60 


3M 
Male 
3372-1302 
60 


3M 
Female 
3334-6000 
60 


PHYSICAL 
PROPERTIES 


Conductors 
- 
28 AWG, 7/36 strand, 
tinned 
copper 


Conductor 
Insulation 
- 
0.010 inch wall, nominal 


Conductor 
Spacing 
- 
Twisted 
pair - 0.10 inch, 


nominal; 
Flat - 0.050 inch, ± 10% 


Cable Thickness 
- 
Flat - 0.042 inch, nominal 


Temperature 
Rating - 
80°C 


ELECTRICAL 
PROPERTIES 


Impedance 
(nominal) 
- 
105 ohms ± 10% 


Propagation 
Velocity 
(nominal) 
- 
1.7 nslft 


Capacitance 
(nominal) 
- 
22 pflft 


INSULATION 
REQUIREMENTS 


Voltage 
Rating (minimum) 
- 
100 Vdc 


Insulation 
Resistance 
(minimum) 
- 
1 x 1010 ohms 


Environmental Characteristics 


Temperature 
- 
0 - 55°C 


Humidity 
- 
90% max. relative (no condensation) 
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• High bus bandwidth 


- 
9.5 Mbytes/sec. 
for 8·bit transfers 


- 
19 Mbytes/sec. 
for 16-bit transfers 


• Supports Up to 5 iLBX™ compatible 


devices per bus 
. 


• Primary and secondary master bus 


exchange capabilities 


• Standard 60-pin MULTIBUS® P2 


connector 


• 16 Mbyte addressing range 


• 8 and 16-bit data transfers 


The iLBX™ Execution 
Bus is one of a family of standard 
bus structures 
resident within Intel's total system architec- 


ture. The Local Bus Extension 
(iLBX) Bus is a dedicated 
execution 
bus capable of significantly 
increasing 
system 


performance 
by extending 
the processor 
board's on-board local bus to oft-board resources. 
This extension 
provides 
for arbitration-free, 
direct access to high-performance 
memory. 
Acting as a "virtual" 
iSBC@, up to 16 megabytes 


of processor 
addressable 
memory 
can be accessed 
over the iLBX bus and appear as though 
it were resident 
on 
the processor 
board. The iLBX Bus preserves 
advantages 
in performance 
and architecture 
of on-board 
memory, 


while allowing 
memory 
configurations 
larger than possible 
on a single board computer. 
High throughput 
and in- 


dependence 
from MULTIBUS@activities 
make the iLBX bus an ideal solution 
for "working 
store" 
type program 


memory and data processing 
applications 
requiring 
large amounts of high performance 
memory. Such applications 


include 
graphics 
systems, 
robotics, 
process control, 
office systems, 
and CAD/CAM. 
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are trademarks 
of Inlel Corporation 
and may be used only to describe 
Intet products: 
Intel, ICE, 
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iRMX, 
iSSe, 
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iSXM, 
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Multichannel 
and MUL TIMODULE. 
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for the use of any circuitry 
other 
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in an Intel product. 
No other circuit 
patent 
licenses 
are implied. 
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contained 
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on these 
devices 
from 
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The iLBX bus is an architectural 
solution for supporting 


large amounts 
of high performance 
memory. 
It is the 


first structure 
that allows the CPU board selection to be 


decoupled 
from the on-board memory requirement, 
and 


still maximizes 
the processor's 
performance 
potential. 


It eliminates the processor's 
need to access its off-board 


memory 
resources 
solely over the MULTIBUS 
system 


bus. Architectural 
consistency 
with the single 
board 


computer 
approach 
including 
iLBX 
memory 
can be 


maintained 
by dual port access of memory 
resources 


between the iLBX bus and the MULTI BUS system bus. 
This allows for global access by other processors 
and 


110 devices while still providing 
high speed local CPU 


operations. 
This sub-system 
created by the iLBX bus of 


a single board computer 
and a maximum 
of 4 memory 


cards 
can be perceived 
architecturally 
as a "virtual 


single 
board computer". 
The implementation 
of iLBX 


bus "virtual 
modules" 
makes it possible to create func- 
tional modules with a new level of flexibility and perform- 
ance in implementing 
a wide range of memory capabili- 


ties. With future 
needs in mind, the iLBX bus has the 


capability 
of accessing 
a full 16 megabytes 
of memory. 


The iLBX bus uses a non-multiplexed 
16-bit configura- 
tion capable of 8 and 16-bit transfers. 
Used in conjunc- 
tion with the MUL TIBUS interface, the iLBX bus resides 
on the MUL TIBUS form factor P2 connector 
and super- 


cedes the MUL TIBUS interface definitions for the P2 sig- 
nals. The iLBX bus uses the standard 60-pin MUL TIBUS 
P2 connector 
and occupies 
56 of the P2 connector 
pins. 


with 16data lines, 24 address 
lines plus control, 
com- 


mand access, and parity signals. The four MUL TIBUS 
address 
extension 
lines on the MUL TIBWSIiLBX 
P2 


connector 
retain the standard MUL TIBUS interface defi- 


nition. 


The iLBX bus supports three distinct device categories: 
1) Primary Master, 2) Secondary Master, 3) Slave. These 
three device types may be combined 
to create several 
iLBX local busses ranging (in size) from a minimum 
of 


two to a-maximum 
of five devices per iLBX bus. There 


is only one Primary Master in any given implementation 
of iLBX bUs, and its presence is required along with the 
attachment 
of at least one Slave device. 
To provide 


alternate 
access over an iLBX bus, one optional 
Sec- 


inter 


ondary 
Master may be incorporated 
to create a "two- 


master" 
local bus subsystem. 
By limiting the iLBX bus 


to two masters (a Primary and a Secondary), 
bus arbi- 


tration is reduced to a simple request and acknowledge 
process, 
with privileged 
use of the bus maintained 
by 


the Primary 
Master, and limited access granted 
to the 


Secondary 
Master when needed. 


The Primary Master executes the role of iLBX bus "super- 
visor" 
by controlling 
the general 
operation 
of the bus 


and managing Secondary 
Master accesses to the Slave 


memory 
resources. 


The Secondary 
Master Device is an option providing 
al- 


ternate access to the Slave resources 
on the iLBX bus. 
Secondary 
master 
devices 
are typically 
DMA driven. 


This feature 
is provided 
for implementation 
flexibility 


when 
occasional 
DMA transfers 
in and out of iLBX 


memory resources can optimize the overall system per- 
formance. The Secondary 
Master essentially duplicates 


the Primary Master's 
data transfer capability, 
but must 


rely on the Primary 
Master to grant access. 
Once ac- 


cess is granted, the Secondary 
Master controls the bus, 
and drives all signal lines until the operation 
is complete 


and control 
is passed back to the Primary 
Master. 


The Slave devices contain the memory resources 
used 


by the Primary Master and the optional Secondary Master. 
Each iLBX implementation 
can contain 
a maximum 
of 


four Slave devices. Using 64K RAM technology 
on four 


slave devices 
with ECC can provide 
for over 2 mega- 
bytes of "on-board" 
high performance 
memory. 
With 


256K RAM chips, 
each iLBX bus could contain 
slave 


devices with memory totalling 8 megabytes. As memory 
technology 
increases, 
the iLBX bus is designed 
to in- 


corporate 
it in rapid fashion 
because 
it is capable 
of 


directly accessing 
a full 16 megabytes 
of memory on its 


high-performance 
Slave devices. 


Bus Interface/Signal 
Line Descriptions 


The iLBX bus interface 
is divided 
into four functional 


classes of signal lines: address and data lines, control 
lines, command 
lines, and bus access lines. The 40 ad- 


dress and data lines defined by the iLBX Bus Specifica- 
tion consist 
of 16 data lines and 24 address 
lines. 


There are 16 bi-directional 
data lines exclusively 
used 


to handle 8-bit and 16-bit data transfers between the ac- 
tive bus master and the selected slave device. The iLBX 
bus uses these data lines for all data transfers, 
and are 


driven 
by tri-state 
drivers. 


The 24 address lines on the iLBX bus provide the abili- 
ty to directly 
address 
16 megabytes 
of memory. 
These 


single-direction 
address lines are exclusively 
driven by 


the active bus master. The iLBX bus master uses them 
to select 
a specific 
slave device. 
Three 
control 
lines 


specify 
the type of data transfer 
between 
master and 


slave devices, 
while the three command 
lines initiate, 


control, and terminate the transfer. There are also three 
bus access lines used to transfer 
bus control 
between 


master devices. 


Bus Pin Assignments 


The iLBX bus uses the standard 
60-pin MUL TIBUS P2 


connector. 
The physical location of each pin assignment 


and its corresponding 
function 
is listed in Table 1.The 


four MUL TIBUS address extension 
lines (pins 55-58 on 


the P2 connector) 
retain the standard 
MUL TIBUS inter- 


face functions. 


Bus Operation Protocol 


The operation 
protocol 
for the iLBX bus is a straight- 


forward set of procedures consisting of three basic oper- 
ations: bus control access, write data to memory, 
read 


data from memory. These operations 
use asynchronous 


protocol 
with positive 
acknowledgment. 


Bus Access 


The iLBX bus is shared by at most two masters; one Pri- 
mary Master and one optional Secondary 
Master, each 


providing an alternate access path to iLBX bus memory 
resources. 
The mechanism 
for obtaining 
bus access is 


a simple request and acknowledge 
process communi- 


cated between masters. Each master is a bus controller 
of similar 
capabilities, 
responsible 
for data transf~r 


operations 
between 
devices, 
but the Primary 
Master 


has the added 
responsibility 
of controlling 
iLBX 
bus 


accesses. 


The Primary Master has default control of the iLBX bus. 
If the Secondary 
Master 
needs access 
to the bus, it 


must initiate 
a request 
and wait for acknowledgment 


from the Primary Master. The choice of when to surren- 
der control of the bus rests with the Primary Master, but 
if no data transfer is in progress, the Primary Master nor- 
mally relinquishes 
control immediately 
to the Secondary 


Master. 


Data Transfer Operation 


The iLBX bus supports two types of data transfer opera- 
tions: write data to memory and read data from memory. 
These data transfer operations 
facilitate 
the passing of 


information 
between the active bus master and the se- 


lected slave device. The operation 
of these two transfer 


types 
is very similar; 
the only differences 
being 
the 


direction 
of the data transfer and the device driving the 


data lines. 


For either type of data transfer, 
the active bus master 


first initiates the transfer operation 
by placing the mem- 


ory address on the address lines (AB23-ABO) and a con- 


trol configuration 
on the control lines to select the slave 
device. 
Once the slave device is selected, 
the type of 
data transfer 
becomes 
the key factor. 
With the write 
operation, 
the active 
master 
maintains 
control 
of the 
data lines and provides 
valid data within the specified 
time. Upon accepting 
a data element, 
the slave sends 
a receipt 
acknowledgment 
signal to the master which 
completes 
the data transfer 
operation. 


With the read operation, the slave device drives the data 
lines and places 
valid data on the data lines 
before 


sampling by the active master. The slave acknowledges 
the master to signal the end of the data transfer, and the 
master completes 
the operation. 


The iLBX Bus Specification 
includes provisions for both 


optimized 
and non-optimized 
data transfers. 
Optimized 


Component 
Side 
Solder Side 


16-Bit Pin 
Mnemonic 
Signal Name 
16-Bit Pin 
Mnemonic 
Signal Name 


1 
DBO 
DATA LINE 0 
2 
DB1 
DATA LINE 
1 


3 
DB2 
DATA LINE 2 
4 
DB3 
DATA LINE 3 


5 
DB4 
DATA LINE 4 
6 
DB5 
DATA LINE 5 


7 
DB6 
DATA LINE 6 
8 
DB7 
DATA LINE 7 


GND 
GROUND 
10 
DB8 
DATA LINE 8 
- 


9 


11 
DB9 
DATA LINE 9 
12 
DB10 
DATA LINE 
10 


13 
DB11 
DATA LINE 
11 
14 
DB12 
DATA LINE 
12 


15 
DB13 
DATA LINE 
13 
16 
DB14 
DATA LINE 
14 


H 
DB15 
DATA LINE 
15 
18 
GND 
GROUND 


19 
ABO 
ADDRESS 
LINE 0 
20 
AB1 
ADDRESS 
LINE 
1 


21 
'AB2 
ADDRESS 
LINE 2 
22 
AB3 
ADDRESS 
LINE 3 


23 
AB4 
ADDRESS 
LINE 4 
24 
AB5 
ADDRESS 
LINE 5 


25 
AB6 
ADDRESS 
LINE 6 
26 
AB7 
ADDRESS 
LINE 7 


27 
GND 
GROUND 
28 
AB8 
ADDRESS 
LINE 8 


29 
AB9 
ADDRESS 
LINE 9 
30 
AB10 
ADDRESS 
LINE 
10 


31 
AB11 
ADDRESS 
LINE 
11 
32 
AB12 
ADDRESS 
LINE 
12 


33 
AB13 
ADDRESS 
LINE 
13 
34 
AB14 
ADDRESS 
LINE 
14 


35 
AB15 
ADDRESS 
LINE 
15 
36 
GND 
GROUND 


37 
AB16 
ADDRESS 
LINE 
16 
38 
ABH 
ADDRESS 
LINE 
17 


39 
AB18 
ADDRESS 
LINE 
18 
40 
AB19 
ADDRESS 
LINE 
19 


41 
AB20 
ADDRESS 
LINE 20 
42 
AB21 
ADDRESS 
LINE 21 


43 
AB22 
ADDRESS 
LINE 22 
44 
AB23 
ADDRESS 
LINE 23 


45 
GND 
GROUND 
46 
ACK' 
SLAVE 
ACKNOWLEDGE 


47 
BHEN 
BYTE 
HIGH 
ENABLE 
48 
RIW 
READ 
NOT WRITE 


49 
ASTB' 
ADDRESS 
STROBE 
50 
DSTB' 
DATA STROBE 


51 
SMRQ' 
SECONDARY 
52 
SMACK' 
SECONDARY 
MASTER 


MASTER 
REQUEST 
ACKNOWLEDGE 


53 
LOCK' 
ACCESS 
LOCK 
54 
GND 
GROUND 


55 
ADR22' 
MULTIBUS" 
ADDRESS 
56 
ADR23' 
MULTIBUS'!J ADDRESS 


EXTENSION 
LINE 22 
EXTENSION 
LINE 23 


57 
ADR20' 
MULTIBUS'!J ADDRESS 
58 
ADR21 , 
MUITIBUS" 
ADDRESS 


EXTENSION 
LINE 20 
EXTENSION 
LINE 21 


59 
RES 
RESERVED 
60 
TPAR* 
TRANSFER 
PARITY 


inter 


operation 
uses pipelining 
and signal overlapping 
tech- 


niques to manage the data transfer timing relationships 
between the,active 
bus master and the selected 
slave. 


The use of signal overlapping 
requires that every device 


attached 
to the iLBX bus provide 
a means for varying 


the timing 
of the slave request 
and acknowledge 
sig- 
nals. The non-optimized 
operation 
uses fixed signal se- 
quences, instead of signal overlapping, 
to assure a valid 


data transfer, 
and a device does not need a variable re- 


quest or acknowledge 
to read data-valid 
timing on the 


iLBX bus. Please refer to the iLBX Bus Specification 
for 


detailed 
descriptions 
of these transfer 
operations. 


Mechanical Implementation 


Because 
the iLBX bus uses the P2 connector 
of the 


MULTIBUS form factor, the iLBX bus "shares" 
a MULTI- 


BUS chassis 
with the MUL TIBUS 
backplane 
system 


bus in the system design. The iLBX mechanical 
spec i- 
fications 
are synonymous 
with the MUL T1BUS specifi- 
cations 
for board-to-board 
spacing, 
board 
thickness, 
component 
lead length, and component 
height above 


the board. The iLBX bus interconnection 
can use either 


flexible ribbon cable or a rigid backplane. 
The iLBX bus 


interconnect 
maximum 
length 
is limited 
to 10 cm (ap- 


proximately 
4 inches); that is sufficient 
to span 5 card 


slots across two connected 
chassis. 
Figure 2 shows an 


iLBX bus cable assembly. 


Figure 2. 
Typical 
iLBX™ Bus Interface 


Cable Assembly 


Word Size 


Data - 
a and 16-bit 


Memory Addressing 


24-bits - 16 megabyte 
- direct access 


Bus Bandwidth 


9.5 megabytes/see 
- 
a-bit 


. 19 megabytes/see 
- 
16-bit 


Signal 
Driver 
Termination 
Min. Driver Requirements 
Max. Receiver 
Requirements 


Name 
Type 
(to + 5 Vde) 
At Master 
High 
Low 
Load Cap. 
High 
Low 
Load Cap. 


D815-0 
TAl-STATE 
10K Ohms 
0.4 ma 
9 ma 
75 pf 
0.15 ma 
2 ma 
18 pI 


TPAR* 
TAl-STATE 
10K Ohms 
0.4 ma 
9 ma 
75 pI 
0.15 ma 
2 ma 
18 pI 


A823-0 
TAl-STATE 
None 
0.4 ma 
20 ma 
120 pI 
0.10 ma 
5 ma 
30 pI 


AIW 
TAl-STATE 
None 
0.2 ma 
8 ma 
75 pI 
0.05 
ma 
2ma 
18 pI 


8HEN 
TAl-STATE 
None 
0.2 ma 
8 ma 
75 pI 
0.05 
ma 
2ma 
18 pI 


lOCK" 
TAl-STATE 
None 
0.2 ma 
8ma 
75 pI 
0.05 ma 
2ma 
18 pI 


SMAQ" 
TIl 
10K Ohms 
0.05 ma 
8ma 
20 pI 
0.05 ma 
2ma 
18 pI 


SMACK" 
TIl 
None 
0.05 ma 
2ma 
20 pI 
0.05 ma 
2ma 
18 pI 


fASTS" 
TAl-STATE 
10K Ohms 
0.2 ma 
9 ma 
75 pI 
0.05 ma 
2 ma 
18 pI 


fDSTS" 
TAl-STATE 
10K Ohms 
0.2 ma 
9 ma 
75 pI 
0.05 ma 
2 ma 
18 pI 


ACK" 
OPEN 
COlL. 
330 Ohms 
N.A. 
20 ma 
45 pI 
0.05 ma 
2 ma 
18 pI 
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Cables and Connectors 


Table 3. 
Cable and Receptacle 
Vendors 


iLBX™ Bus Compatible 
Cable 


Vendor 
Vendor Part No. 
Conductors 


T&B 
Ansley 
171-60 
60 


T&B 
Ansley 
173-60 
60 


3M 
3365/60 
60 


3M 
3306/60 
60 


Berg 
76164-060 
60 


Belden 
9L28060 
60 


Spectrastrip 
455-240-60 
60 


iLBX™ Bus Compatible 
Receptacles 


Vendor 
Vendor Part No. 
Pins 


Kelam 
RF30-2803-5 
60 


T&B 
Ansley 
A3020 
60 


(609-6025 
modified) 


Temperature 
- 
0 to 55°C 


Relative Humidity - 
0 to 85 percent; 
non-condensing 
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• IEEE P959 industry standard I/O 
expansion bus 


• Provides on-board expansion of 
system resources 


• Small iSBX™ MULTIMODULE™ boards 
plug directly into iSBC® boards 


• Supports compatible 8- and 16-bit data 
transfer operations 


• Part of Intel's Total System 
Architecture: MULTIBUS~ iLBXiM 


MULTICHANNELiM and iSBX™ 


• Low-cost "vehicle" 
to incorporate the 


latest VLSI technology into 
iSBC®-based systems 


• Provides increased functional capabili- 


ty and high performance 


• Supported bya complete line of 
iSBC®base boards and iSBX™ 
MULTIMODULETMboards, providing 
analog and digital I/O, high-speed math, 
serial and parallel I/O, video graphics, 
and peripheral controllers 


The iSBX™ I/O Expansion 
Bus is one of a family 
of standard 
bus structures 
resident 
within 
Intel's 
total system 
architecture. 
The iSBX bus is a modular, 
I/O expansion 
bus capable of increasing 
a single board computer's 
func- 
tional capability 
and overall performance 
by providing 
a structure 
to attach sr:nall iSBX MULTIMODULETM boards 
to iSBC® base boards. It provides for rapid incorporation 
of new VLSI into iSBC MUL TIBUS® systems, 
reducing 
the 


threat of system obsolescence. 
The iSBX bus offers users new economics 
in design by allowing 
both system size 
and system cost to be kept at minimum. 
As a result, the system design achieves 
maximum 
on-board 
performance 
while allowing 
the MUL TIBUS interface to be used for other system activities. 
The iSBX bus enables 
users to add- 


on capability 
to a system as the application 
demands 
it by providing 
off-the-shelf 
standard 
MULTIMODULE 
boards 
in the areas of graphics controllers, 
advanced 
mathematics 
functions, 
parallel-and serial I/O, disk and tape peripheral 
controllers, 
and magnetic 
bubble memory. 
A full line of MUL TIBUS boards and iSBX MULTIMODULE 
boards are 


available 
from Intel and other third party sources 
in the industry. 


The following 
are trademarks 
at Inlet Corporation 
and may be used only to describe 
Intet products: 
Intel, 
ICE. 
iMMX, 
iR~X. 
iSBC, 
iSBX, 
iSXM, 
MUL TIBUS, 
Multichannel 
and MUL TIMODULE. 
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Bus Elements 


The iSBX'" 
MULTI MODULE'" 
system is made up of two 


basic elements: base boards and iSBX MUL TIMODULE 
boards. 
In an iSBX system, 
the role of the base board 


is simple. 
It decodes 
1/0 addresses 
and generates 
the 


chip selects 
for the iSBX MUL TIMODULE 
boards. 


The iSBX bus supports 
two classes 
of base boards, 
those with direct 
memory 
access 
(DMA) support 
and 


those without. Base boards with DMA support have DMA 
controllers that work in conjunction 
with an iSBX MUL TI- 
MODULE 
board (with DMA capability) 
to perform direct 


1/0 to memory or memory to 1/0 operations. Base boards 
without 
DMA support use a subset of the iSBX bus and 


simply do not use the DMA feature of the iSBX MUL TI- 
MODULE 
board. 


The iSBX MULTIMOPULE 
boards are small, specialized, 
1/0 mapped 
boards which plug into base boards. The 


iSBX boards 
connect 
to the iSBX bus connector 
and 


convert 
iSBX bus signals to a defined 
1/0 interface. 


Bus Interface/Signal 
Line Descriptions 


The iSBX bus interface 
can be grouped 
into six func- 


tional 
classes: 
control 
lines, address 
and chip select 


lines, data lines, interrupt lines, option lines, and power 
lines. The iSBX bus provides 
nine control lines that de-. 


fine the communications 
protocol between 
base board 


and iSBX MUL TIMODULE 
boards. These control 
lines 


are used to manage the general operation 
of the bus by 


specifying 
the type of transfer, 
the coordination 
of the 


transfer, 
and the overall state of the transfer 
between 


devices. 
The five address 
and chip select signal lines 


are used in conjunction 
with the commmand 
lines to 


establish the I/O port address being accessed, effectively 
selecting 
the proper 
iSBX MUL TIMODULE. 
The data 


lines on the iSBX bus can number 8 or 16, and are used 
to transmit 
or receive 
information 
to or from the iSBX 


MUL TIMODULE 
ports. Two interrupt lines are provided 


to make interrupt requests possible from the iSBX board 
to the base board. Two option lines are reserved on the 
bus. for unique user requirements, 
while several power 


lines provide 
+ 5 and ± 12 volts to the iSBX boards. 


Bus Pin Assignments 


The iSBX bus uses widely available, reliable connectors 
that are available in 18/36 pin for 8-bit devices and 22/44 
pin for 16-bit devices. 
The male iSBX connector 
is at- 


tached to the iSBX MUL TIMODULE board and the female 
iSBX connector 
is attached' to the base board. Figure 


2 shows the dimensions 
and pin numbering 
of the 18/36 


pin iSBX connector, 
while Figure 3 does the same for 


the 22/44 pin iSBX connector. 
A unique scheme allows 


the 16-bit female connector 
to support 8 or 16-bit male 


MUL TIMODULE 
boards. 
Table 
1 lists the signallpin 


assignments 
for the bus. 


Pin' 
Menmonlc 
Description 
Pin' 
Mnemonic 
Description 


43 
M08 
MOATA Bit 8 
44 
M09 
MOATA Bit 9 


41 
MOA 
MOATA Bit A 
42 
MOB 
MOATA Bit F 


39 
MDC 
MOATA Bit C 
40 
MOD 
MOATA Bit 0 


37 
MOE 
MOATA Bit E 
38 
MOF 
MOATA Bit F 


35 
GNO 
Signal Gnd 
36 
+5V 
+5 Volts 


33 
MOO 
MOATA Bit 0 
34 
MORQT 
M OMA Request 


31 
M01 
MOATA Bit 1 
32 
MOACKI 
M OMA Acknowledge 


29 
M02 
MOATA Bit 2 
30 
OPTO 
Option 
0 


27 
M03 
MOATA Bit 3 
28 
OPT1 
Option 
1 


25 
M04 
MOATA Bit 4 
26 
TOMA 
Terminate 
OMA 


23 
M05 
MOATA Bit 5 
24 
Reserved 


21 
M06 
MOATA Bit 6 
22 
MCSOI 
M Chip 
Select 0 


19 
M07 
MOATA Bit 7 
20 
MCS11 
M Chip 
Select 
1 


17 
GNO 
Signal 
Gnd 
18 
+5V 
+5 Volts 


15 
10ROI 
1/0 
Read Cmd 
16 
MWAITI 
M Wait 


13 
10WRTI 
1/0 Write Cmd 
14 
MINTRO 
M Interrupt 
0 


11 
MAO 
M Address 
0 
12 
MINTR1 
M Interrupt 
1 


9 
MA1 
M Address 
1 
10 
Reserved 


7 
MA2 
M Address 
2 
8 
MPSTI 
iSBX Multimodule 
Board 
Present 


5 
RESET 
Reset 
6 
MCLK 
M Clock 


3 
GNO 
Signal Gnd 
4 
+5V 
+5 Volts 


1 
+12V 
+12 Volts 
2 
-12V 
-12 Volts 


Notes: 
1. Pins 37-44 are used only on 8/16-bit 
systems 


2. All undefined 
pins are reserved for future 
use. 


COMMAND 
OPERATION 


The iSBX bus supports two types of transfer operations 
between 
iSBX elements: 
1/0 Read and I/O Write. An 


iSBX board can respond 
to these 
1/0 transfers 
using 


either full speed mode or extended 
mode. 


For a full speed 
I/O Read (Figure 
4) the base board 


generates 
a valid 1/0 address and a valid chip select for 


the iSBX MUL TIMODULE 
board. After set-up, the base 


board activates the 1/0 Read line causing the iSBX board 


to generate valid data from the addressed 
I/O port. The 


base board then reads the data and removes the read 
command, 
address, and chip select. The full speed I/O 


Write (Figure 5) operation 
is similar to the I/O Read ex- 


cept that the base board generates 
valid data on the 


lines and keeps the write command 
line active for the 


specified 
a hold time. 


The extended Read operation (Figure 6) is used by iSBX 
MUL TIMODULE 
boards that aren't configured 
to meet 


full speed specifications. 
It's operation 
is similar to full 


speed mode, but must use a wait signal to ensure proper 


inter 


data transfer. 
The base board begins the operation 
by 
generating 
a valid 1/0 address and chip select. After set- 


up, the base board activates the Read line causing the 
iSBX board to generate 
a Wait signal. This causes the 
CPU on the base board to go into a wait state. When the 
iSBX board 
has placed 
valid 
Read data on the data 
lines, the MUL TIMODULE 
board will remove the Wait 
signal and release the base board CPU to read the data 
and deactivate the command, 
address, and chip select. 


The extended Write operation (Figure 7) is similar to the 
extended 
Read except that the Wait signal is generated 
after the base board places valid Write data on the data 
lines. The iSBX board removes the Wait signal when the 
write pulse width 
requirements 
are satisfied, 
and the 
base board can then remove the write command 
after 
the hold time is met. 


DMA OPERATION 


An iSBX MULTIMODULE system can support DMA when 
the base board has a DMA controller and the iSBX MULTI- 
MODULE 
board can support 
DMA mode. Burst mode 
DMA is fully supported, but for clarity and simplicity, only 
a single 
DMA transfer 
for an 8-bit base board 
is dis- 


cussed. 


A DMA cycle (Figure 8) is initiated 
by the iSBX board 
when it activates the DMA request line going to the DMA 
controller 
on the base board. When the DMA controller 


gains control 
of the base board bus, it acknowledges 
back to the iSBX board and activates an 1/0 or Memory 
Read. The DMA controller then activates an 1/0 or Mem- 
ory Write 
respectively. 
The iSBX board 
removes 
the 
DMA request during the cycle to allow completion 
of the 
DMA cycle. Once the write operation 
is complete, 
the 
DMA controller 
is free to deactivate 
the write and read 
command 
lines after a data hold time. 


INTERRUPT 
OPERATION 


The iSBX MUL TIMODULE 
board on the iSBX bU~ can 
support interrupt operations 
over its interrupt lines. The 
iSBX board initiates an interrupt 
by activating 
one of its 


two interrupt lines which connect to the base board. 1 ne 
CPU processes the interrupt and executes the interrupt 
service routine. The interrupt service routine signals the 
iSBX MUL TIMODULE 
board to remove the interrupt, 


and then returns control to the main line program when 
the service 
routine 
is completed. 


Please refer to the Intel iSBX Bus Specification 
for more 
detailed information on its operation and implementation. 


Word Size 


Data - 
8, 16-bit 


Power Supply Specifications 


Table 3. 


Minimum 
Nominal 
Maximum 
Maximu"1 


(volts) 
(volts) 
(volts) 
(current) 


+475 
-+ 5.0 
+5.25 
3.0A 


+11.4 
..-12 
+12.6 
lOA 


··126 
-12 
-11.4 
10A 


- 
GND 
- 
3.0A 


iSBX ™ 
Connector 
Chip 
8-BIt Base 
16-Bit Base 
16-BII Base 
Number 
Select 
Board Address 
Board Address 
Board Address 


(8-blt 
mode) 
(l6-blt 
mode) 


iSBXTM 1 
MCSO/ 
FO-F7 
OAo-OAF 
OAO,2, 4, 6, 8, 


MCS1/ 
F8·FF 
OBo-OBF 
A.C,E 
OA1, 3, 5, 7. 9, 
B, 0, F 


iSBXTM 2 
MCSO/ 
CO-C7 
OBo-08F 
080, 2, 4, 6, 8, 


MCS1/ 
C8-CF 
090-09F 
A,C,E 
081,3,5,7.9, 
B,D.F 


iSBxn. 
3 
MCSO/ 
BO-B7 
06o-06F 
060. 2. 4, 6. 8, 


MCS1/ 
B8-BF 
060-06F 
A,C,E 
061,3,5.7,9, 
B, D. F 


Table 4. ISBXTM MULTIMODULE™ 
Board 
I/O DC Specifications 


Output' 


Bus Signal 
Type' 
10L Max 
@ Volls 
10H Mu 
@ Volls 
Co (Mln) 
Name 
Drive 
-Mln 
(mA) 
(VOL Mall) 
-Mln 
(PA) 
(VOH Mln) 
(pI) 


MDD-MDF 
TRI 
1.6 
0.5 
-200 
24 
130 


MINTRO-1 
TTL 
20 
0.5 
-100 
2.4 
40 


MDROT 
TTL 
1.6 
0.5 
-SO 
2.4 
40 


MWAITI 
TTL 
1.6 
05 
- 
50 
2.4 
40 


OPT1-2 
TTL 
16 
0.5 
- 
50 
2.4 
40 


MPSTI 
TTL 
Note 3 


Bus Signal 
Type' 
IlL Mall 
@ V'N MAX 
IIH Mall 
@ V,N MAX 
C, Mu 
Name 
Receiver 
(mA) 
(volls) 
(PA) 
(volls) 
(pI) 
Test Condo 
T-t 
Condo 


MDD-MDF 
TRI 
-0.5 
0.4 
70 
2.4 
40 


MAO-MA2 
TTL 
-05 
0.4 
70 
2.4 
40 


MCSOI-MCS11 
TTL 
'-4.0 
0.4 
100 
2.4 
40 


MRESET 
TTL 
-21 
0.4 
100 
2.4 
40 


MDACKl 
TTL 
-1.0 
0.4 
100 
2.4 
40 


10RDI 
TTL 
-10 
0.4 
100 
40 
10WRTI 
2.4 


MCLK 
TTL 
- 2.0 
0.4 
100 
2.4 
40 


OPT1-0PT2 
TTL 
-2.0 
0.4 
100 
2.4 
40 


NOTES 
1 Per ISBX Multlmodule 
1/0 board. 
All Inputs: 
Max V,L = 0.8V 


2 
TTL = standard 
totem 
pole output. 
TRI = Three-state. 
Min V,H = 2.0V 


3. ,SBX Mult,module 
board 
must connect 
this signal to ground. 
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Figure 
6. 
iSBX™ MULTIMODULETM 
Board 
Extended 
Read 
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Figure 8. ISBXTM MULTIMODULETM 
Boerd 
DMA Cycle 
(iSBXTt' MULTIMODULETM 
to Base Board 
Memory) 
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Environmental Characteristics 


Operating 
Temperature 
- 
0 to 55°C 


Humidity 
- 
90% maximum 
relative; 
non-condensing 


Reference Manuals 


210883 - 
MULTIBUS 
Handbook 


• iAPX 286/10 (80286) Microprocessor 


with 6.0 MHz CPU clock 


• Optional 80287 Numeric Data 


Processor 


• iLBX™ (Local Bus Extension) interface 


for high-speed memory expansion 


• Two iSBX™ bus interface connectors 


for 110 expansion 


• Eight JEDEC 28-pin sites for optional 


RAM/iRAM/EPROM/E 
2 PROM 


components 


• Optional expansion to twelve JEDEC 


28-pin sites with an iSBC@341 28-pin 
site expansion board 


• 16 levels of vectored interrupt control 


• Centronics-compatible 
parallel 110 


printer interface 


• Two programmable multi protocol 


synchronous/asynchronous 
serial 


interfaces; one RS232C, the other 
RS232C or RS422 compatible 


• MULTIBUS@interface for multimaster 


configurations and system expansion 


The iSBC'" 286/1 0 Single 
Board Computer 
is a member 
of Intel's 
complete 
line of microcomputer 
modules 
and 


systems which take advantage 
of Intel's VLSI technology 
to provide economical, 
off-the-shelf, 
computer-based 
solu- 
tions for OEM applications. 
The board is a complete 
microcomputer 
system on a 6.75 x 12.0 inch printed circuit card. 


The CPU, system clock, memory sockets, 
I/O ports and drivers, 
serial communications 
interface, 
priority 
interrupt 


logic and programmable 
timers, all reside on the board. The iSBC 286/10 board is the first single board computer 


to incorporate 
the iAPX 286 CPU and the iLBXTMbus extension. 
This combination 
provides 
the highest 
perform- 


ance 16-bit microcomputer 
system solution. 
The iLBX architectural 
expansion 
maintains 
this high performance 
for 


applications 
requiring 
vast amounts 
of system memory. 


Overview 


The iSBC 286/10 board utilizes the powerful 
iAPX 286 
CPU within 
the MUL TIBUS 
system 
architecture, 
en- 
hanced by the iLBX bus, to provide a high performance 
16-bit solution. This board also includes on-board inter- 
rupt, memory 
and I/O features 
facilitating 
a complete 
single board computer 
system. 


Central Processing Unit 


The central processor 
for the iSBC 286/10 board is the 
80286 
CPU operating 
at a 6.0 MHz clock 
rate. The 
80286 CPU is upwardly compatible 
with Intel's iAPX 88 
and iAPX 86 CPUs. The 80286 CPU runs iAPX 88 and 
86 code at substantially 
higher speeds due to a parallel 
chip architecture. 
In addition, 
the 80286 CPU provides 
on chip memory management 
and protection and virtual 
memory 
addressing 
of up to 1 gigabyte 
per task. Nu- 
meric processing 
power may be enhanced 
with the op- 
tional 80287 numerics processor. The clock rates for the 
80286 and the 80287 are independent 
with the 80287 
rate jumper 
selectable 
at either 4.0 or 8.0 MHz. 


Instruction Set 


The 80286 instruction repertoire includes variable length 
instruction format (including double operand instructions), 
8-bit and 16-bit signed and unsigned 
arithmetic 
opera- 
tors for binary, 
BCD and unpacked 
ASCII 
data, 
and 
iterative 
word and byte string manipulation 
functions. 


For enhanced 
numerics 
processing 
capability, 
the 
80287 Numeric Data Processor extends the 80286 archi- 
tecture 
and data set. Over 60 numeric 
instructions 
of- 


fer arithmetic, 
trigonometric, 
transcendental, 
logarith- 


mic and exponential 
instructions. 
Supported 
data types 


include 16-, 32-, and 64-bit integer, 32- and 54-bit floating 
point, 18-digit packed BCD and 80-bit temporary. 
The 
80287 
meets 
the proposed 
IEEE 
P754 standard 
for 
numeric 
data processing 
and maintains 
compatibility 
with 8087-based 
systems. 


Architectural Features 


The iAPX 86,88,186, 
and 286 CPU family all contain 
the same basic set of registers, 
instructions, 
and ad- 


dressing 
modes. The 80286 processor 
is upward com- 
patible with the 8086,8088 
and 80186 CPUs. 


The 80286 operates in two modes: iAPX 86 real address 
mode and protected 
virtual address 
mode. In iAPX 86 


real address mode, programs 
use real addresses 
with 


up to one megabyte 
of address 
space. Programs 
use 


virtual 
addresses 
in protected 
virtual 
address 
mode, 
also called 
protected 
mode. 
In protected 
mode, 
the 


80286 CPU automatically 
maps 1 gigabyte of virtual ad- 


dresses per task into a 16 megabyte real address space. 
This mode also provides 
memory protection 
to isolate 


the operating 
system and ensure privacy of each tasks' 
programs and data. Both modes provide the same base 
instruction 
set, registers, 
and addressing 
modes. 


VECTORED 
INTERRUPT 
CONTROL 


Incoming interrupts are handled by two on-board 8259A 
programmable 
interrupt controllers 
and by the 80286's 
NMlline. 
Interrupts 
originating 
from up to 16 sources 
are prioritized 
and then sent to the CPU as a vector ad- 


dress. Further interrupt 
capability 
is available 
through 


bus vectored interrupts where slave 8259 interrupt con- 
trollers 
resident on separate 
SBC boards and are cas- 


caded into the on-board 
interrupt 
co.ntrol. 


Twenty-three 
potential 
interrupt 
sources 
are routed to 
the interrupt jumper matrix where the user can connect 
the desired interrupt sources to specific interrupt levels. 
Table 
1 includes 
a list of devices 
and functions 
sup- 


ported by interrupts. 


MEMORY 
CAPABILITIES 


There are eight 28-pin JEOEC sites on-board which may 
contain 
a combination 
of byte-wide 
devices 
including 


RAM, iRAM, EPROM, 
and E2PROM. 
These sites are 


organized 
into two 4-site blocks, one of which 
may be 


dual-ported. 
The dual port block may be extended 
to 


eight 
sites 
(i.e. 
12 sites total) 
by the addition 
of an 


iSBC 341 JEOEC site expansion 
module. The on-board 


EPROM capacity 
using twelve 27128 EPROMs 
is 192 


Kbytes. The on-board RAM using ten 8K x 8 RAMs is 80 
Kbytes. 


SERIAL 
I/O 


A two channel 
serial communications 
interface 
using 


Intel's 8274 Multi-Protocol 
Serial Controller 
(MPSC) is 


contained 
on the iSBC 286/10 board. Two independent 


software 
selectable 
baud rate generators 
provide 
the 


MPSC with all common 
communication 
frequencies. 


The protocol (i.e. asynchronous, 
IBM bisync, or SOLC/ 


HOLC), data format, control character format, parity and 
baud rate are all under program control. Software inter- 
facing to the MPSC can be via either a polled or inter- 
rupt driven routine. One channel may be configured 
for 


an RS232C or RS422 interface 
with the other channel 


RS232C only. The data, command 
and signal ground 


lines for each channel 
are brought 
out to two 26-pin 


connectors. 


Number 
of 
Device 
Function 
Interrupts 


MULTIBUS 
interface 
Requests 
from 
MULTIBUS"'resident 
peripherals 
or other 
CPU boards 
8" 


8259A 
programmable 
8 level vectored 
interrupt 
request 
cascaded 
to master 
8259A 
1 
interrupt 
controller 


8274 serial 
controller 
8 level vectored 
interrupt 
request 
cascaded 
to master 
8259A 
1 


8255A 
line printer 
Signals 
output 
buffer 
empty 
1 
interface 


8254 timers 
Timer 
0, 1 outputs; 
function 
determined 
by timer 
mode 
2 


4 
iSBXTM connectors 
Function 
determined 
by iSBXTM MULTIMODULETM 
board 
(2 per iSBXTM 


connector) 


Bus fail safe timer 
Indicates 
addressed 
MULTIBUS"resident 
device 
has not responded 
to 
1 
command 
within 
6 msec 


Power 
fail interrupt 
Indicates 
AC power 
is not within 
tolerance 
1 


External 
interrupt 
General 
purpose 
interrupt 
from 
auxiliary 
connector, 
commonly 
used as 
1 
front panel 
interrupt 


On-board 
logic 
Conditioned 
interrupt 
source 
from 
edge sense 
latch, 
inverter, 
or OR gate 
3 


PROGRAMMABLE 
TIMERS 


The iSBC 286/10 
board provides 
three independent, 
fully programmable 
16-bit interval timers/event 
counters 
utilizing 
the Intel 8254 Programmable 
Interval 
Timer. 
Each counter 
is capable of operating 
in either BCD or 
binary modes. Two of these timers/counters 
are avail- 
able to the systems designer to generate accurate time 
intervals under software control. Routing for the outputs 
of these counters is jumper selectable. The outputs may 
be independently 
routed to the 8259A Programmable 
Interrupt Controller or to the 8274 MPSC to count exter- 
nal events or provide baud rate generation. 
The thi.rd in- 


terval timer in the 8254 is dedicated to providing a clock 
for the programmable 
baud rate generator 
in the iSBC 


286/10 board's MPSC serial controller. The system soft- 
ware configures 
each timer independently 
to select the 


desired function. Seven functions are available as shown 
in Table 2. The contents 
of each counter 
may be read 


at any time during system operation. 


Function 
Operation 


Interrupt on 
When terminal count is reached, an 


terminal count 
interrupt request is generated. This 
function is extremely useful for gen- 
eration of real-time clocks. 


Programmable 
Output goes low upon receipt of an 


one-shot 
external trigger edge or software 
command and returns high when 
terminal count is reached. This func- 
tion is retriggerable. 


Rate generator 
Divide by N counter. The output will 
go low for one input clock cycle, and 
the period from one low going pulse 
to the next is N times the input clock 
period. 


Square-wave 
Output will remain high until one-half 


rate generator 
the count has been completed, and 
go low for the other half of the count. 


Software 
Output remains high until software 


triggered 
loads count (N). N counts after count 


strobe 
is loaded, output goes low for one 
input clock period. 


Hardware 
Output goes low for one clock period 


triggered 
N counts after rising edge counter 


strobe 
trigger input. The counter is retrig- 
gerable. 


Event counter 
On a jumper selectable basis, the 
clock input becomes an input from 
the external system. CPU may read 
the number of events occurring after 
the counter "window" has been en- 
abled or an interrupt may be gen- 
erated after N events occur in the 
system. 


LINE PRINTER 
INTERFACE 


An 8255A Programmable 
Peripheral Interface (PPI) pro- 
vides a line printer interface, several on-board functions, 
and four non-dedicated 
input bits. Drivers are provided 
for a complete 
Centronics 
compatible 
line printer inter- 
face. The on-board functions 
implemented 
with the PPI 
are power fail sense, override, 
NMI mask, non-volatile 
RAM enable, clear timeout interrupt, LED 0 and 1, clear 
edge sense flop, MULTI BUS interrupt, 
and serial chan- 
nel A loopback. The PPl's I/O lines are divided into three 
eight bit ports: A, Band C. Four non-dedicated 
input bits 
allow the state of four user configured 
jumper 
connec- 
tions to be input. The PPI must be programmed 
for mode 
o with ports A and C used as outputs and port B as input. 
A "dummy" 
write to port B is used to set the iSBC 286/10 
board to protected 
mode. The parallel 
port bit assign- . 


ment is shown in Table 3. 


Port A - 
Output 


Bit 
Function 


0 
Line Printer Data Bit 0 
1 
Line Printer Data Bit 1 
2 
Line Printer Data Bit 2 
3 
Line Printer Data Bit 3 


4 
Line Printer Data Bit 4 
5 
Line Printer Data Bit 5 


6 
Line Printer Data Bit 6 
7 
Line Printer Data Bit 7 


Port B - 
Input 


Bit 
Function 


0 
General Purpose Input 0 
1 
General Purpose Input 1 
2 
General Purpose Input 2 
3 
General Purpose Input 3 
4 
Line Printer ACKI (Active Low) 


5 
Power Fail Sense/ (Active Low) 


6 
Line Printer Error (Active Hi) 
7 
Line Printer Busy (Active Hi) 


Port C - 
Output 


Bit 
Function 


0 
Line Printer Data Strobe (Active Hi) 


1 
Overridel 
(Active Low) 


2 
NMI Mask (0= NMI Enabled) 
3 
Non-Volatile RAM Enable; Clear Timeout 
Interrupti 


4 
LED 0 (1 = On); Clear Edge Sense Flopl 


5 
MULTIBUS" Interrupt (1 = Active) 


6 
Serial CHA Loopback (0= Online, 1= Loopback) 


7 
LED 1 (1 = On);Clear Line Printer Ack Flopl 


MUL T1BUS® System 
Architecture 


OVERVIEW 


The MUL TIBUS system architecture 
includes three bus 


structures: 
the system bus, the local bus extension 
and 


the MUL TIMODULE™ 
expansion 
bus as shown in Fig- 
ure 2. Each bus structure is optimized to satisfy particu- 
lar system 
requirements. 
The system 
bus provides 
a 


basis for general system design including 
memory and 


I/O expansion 
as well as multiprocessing 
support. The 


local bus extension 
all lows large amounts 
of high per- 
formance 
memory to be accessed 
from a CPU board 


over a private bus. The MULTIMODULE 
extension 
bus 


is a means of adding inexpensive I/O functions to a base 
CPU board. Each of these three bus structures 
are im- 


plemented 
on the iSBC 286/10 board providing 
a total 


system architecture 
solution. 


The MUL TIBUS system bus is Intel's industry standard, 
IEEE 796, microcomputer 
bus structure. 
Both 8- and 


16-bit single 
board 
computers 
are supported 
on the 


IEEE 796 structure 
with 24 address and 16 data lines. 
In its simplest application, 
the system bus allows expan- 
sion of functions 
already contained 
on a single board 


computer 
(e.g., memory and digital I/O). However, the 


IEEE 796 bus also allows very powerful distributed 
pro- 


cessing configurations with multiple processors and intel- 
ligent slave, I/O and peripheral boards capable of solving 
the most demanding 
microcomputer 
applications. 
The 


MUL TIBUS system bus is supported 
with a broad array 


of board level products, 
LSI interface 
components, 
de- 


tailed published 
specifications 
and application 
notes. 


SYSTEM 
BUS - EXPANSION 
CAPABILITIES 


Memory and I/O capacity 
may be expanded 
and addi- 


tional functions 
added using Intel MUL TIBUS compat- 


ible expansion 
boards. 
Memory 
may be expanded 
by 


adding 
user specified 
combinations 
of RAM boards, 


EPROM 
boards, 
or combination 
boards. 
Input/output 


capacity 
may be added with digital 
I/O and analog 
I/O 


expansion 
boards. 
Mass storage 
capability 
may be 


achieved 
by adding 
single or double 
density 
diskette 


controllers, 
or hard disk controllers. 
Modular 
expand- 


able backplanes 
and cardcages are available to support 


multiboard 
systems. 


For those applications 
requiring 
additional 
processing 


capacity and the benefits of multiprocessing 
(i.e., several 


CPUs and/or controllers 
logically sharing system tasks 


through 
communication 
of the system 
bus), the iSBC 


286/10 board provides full system bus arbitration 
con· 


trol logic. This control 
logic allows 
up to three 
iSBC 


286/10 boards or other bus masters, including 
iSBC 80 
family MUL TIBUS compatible 
8-bit single board com- 
puters 
to share the system 
bus using a serial (daisy 


chain) priority scheme 
and allows up to 16 masters to 
share the MUL TIBUS system bus with an external paral- 
lel priority decoder. 
In addition to multiprocessing 
con- 


figuration 
made possible with multimaster 
capability, 
it 
also provides 
a very efficient 
mechanism 
for all forms 
of DMA (Direct Memory Access) transfers. 


iLBX™ BUS - LOCAL BUS EXTENSION 


The iSBC 286/10 board also provides the local bus ex- 
tension (iLBX) of the MULTIBUS architecture. This stand- 
ard extension 
allows on-board 
memory 
performance 


with physically 
off-board 
memory. 
The combination 
of 
a CPU board and iLBX memory boards is architecturally 
equivalent 
to a single board computer 
and thus can be 


called a "virtual 
SBC". 
The iLBX is implemented 
over 


the P2 connector and requires cabling across the virtual 
SBCs of a system (see Figure 3). Other Intel products 
which support 
the iLBX bus include: 


iSBC 028CX 128KB iLBX RAM board 
iSBC 056CX 256KB iLBX RAM board 
iSBC 012CX 512KB iLBX RAM board 
iSBC 428 JEDEC 28-PIN SITE board 
iSBC 580 MULTICHANNEL™ 
interface 
board 


iSBXTMBUS MULTIMODULETM 
ON-BOARD 
EXPANSION 


Two 8/16-bit 
iSBX™ MULTIMODULE 
connectors 
are 
provided 
on the iSBC 286/10 
microcomputer 
board. 


Through these connectors, additional on-board 1/0 func- 
tions may be added. iSBX MUL TIMODULEs 
optimally 


support functions 
provided 
by VLSI peripheral 
compo- 
nents such as additional 
parallel and serial 110, analog 
1/0, small mass storage 
device controllers 
(e.g., cas- 


settes and floppy disks), and other custom interfaces to 
meet specific needs. By mounting directly on the single 
board computer, less interface logic, less power, simpler 


packaging, 
higher performance, 
and lower cost result 
when compared to other alternatives such as MULTIBUS 
form factor compatible 
boards. The iSBX connectors 
on 
the iSBC 286/10 board provide all signals necessary 
to 
interface 
to the local on-board 
bus, including 
16 data 
lines for maximum 
data transfer 
rates. 
iSBX 
MULTI- 


MODULE 
boards 
designed 
with 8-bit data paths and 
using the 8-bit iSBX connector are also supported on the 
iSBC 286/10 microcomputer 
board. A broad range of 
iSBX MUL TIMODULE 
options are available 
from Intel. 


Custom iSBX modules may also be designed. 
An iSBX 


bus interface 
specification 
and iSBX connectors 
are 
available 
from Intel. 


Software Support 


Real-time support for the iSBC 286/10 board is provided 
by the iRMX™ 286R operating 
system. 
iRMX 286R is 


an adaptation 
of iRMX 86 nucleus 
to operate 
on the 


iSBC 286/10 board in real address mode, enhances 
the 


ICU for configuration 
support of the board, adds a driver 


for the on-board 
8274 and supports 
the 80287. 
The 


iRMX 286R Operating 
System is completely 
compatible 


with iRMX 86. 


Interactive 
multi-user 
support 
will be provided 
by the 


XENIX 1 operating system. XENIX is a compatible 
deriv- 


ative of UNIX2, System 
III. 


Language 
support for the iSBC 286/10 boards real ad- 
dress mode includes Intel's ASM 86, PUM 86, PASCAL 
and FORTRAN 
as well as many third party 8086 lan- 


guages. 
Language 
support 
for virtual 
address 
mode 


operation 
includes 
ASM 286, PLIM 286, PASCAL 
and 


C. Programs developed in these languages can be down- 
loaded from an Intel Series III Development 
System to 


the iSBC 
286/10 
board 
via the iSDMTM 286 System 
Debug Monitor. The iSDM 286 monitor also provides on- 
target program debugging 
support including 
breakpoint 
and memory 
examination 
features. 


1 Xenix is a trademark of Microsoft Inc. 
2 UNIX is a trademark of Bell Labs. 


Instruction 
- 
8, 16, 24, 32 or 40 bits 


Data - 
8 or 16 bits 


System Clock 


CPU - 
6.0 MHz 


Numeric 
Processor 
- 
4.0 or 8.0 MHz (Jumper Select- 
able) 


Cycle Time 


Basic Instruction 
- 
6.0 MHz - 500 ns; 333 ns (assumes 
instruction 
in queue) 


NOTE: 
Basic instruction cycle is defined as the fastest instruction 
time (I.e. two clock cycles). 


Memory Capacity (Maximum) 


EPROM - 
2716, 8 Kbytes; 2732, 16 Kbytes; 2764, 64 
Kbytes; 27128, 
128 Kbytes; 27256, 256 Kbytes 


E2PROM 
- 
2817A, 
16 Kbytes 


iRAM - 
2186, 16 Kbytes 


Static 
RAM - 
8K x 8 devices, 
48 Kbytes 


NOTES: Two local sites must contain boot-up EPROM or E2PROM. 


2716s and 2732s may reside in dual-port sites only. iRAMs 
may reside in local sites only. 
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EPROM - 
2716, 16 Kbytes; 2732, 32 Kbytes; 2764, 96 
Kbytes; 27128, 192 Kbytes; 27256, 256 Kbytes 


E 2PROM - 
2817 A, 24 Kbytes 


iRAM - 
2186,16 
Kbytes 


Static 
RAM - 
8K x 8 devices, 
80 Kbytes 


NOTES: 
Dual·port sites can address 128 Kbytes of memory maxi· 
mum. Two local sites must contain boot-up EPROM or 
E2PROM. 2716s and 2732s may reside in dual-port sites 
only. iRAMs may reside in local sites only. 


1/0 Capability 


Parallel - 
Line printer interface, on-board fuctions, and 
four non-dedicated 
input bits 


Serial- 
Two programmable 
channels 
using one 8274 


Timers 
- 
Three programmable 
timers using one 8254 


Expansion 
- 
Two 8/16-bit iSBX MUL TIMOOULE 
con- 


nectors 


Interrupt Capacity 


Potential 
Interrupt 
Sources 
- 
23, jumper 
selectable 


Interrupt 
Levels 
- 
16 vectored 
requests 
using two 


8259As and the 80286's 
NMI line. 


Synchronous 
- 
5-8 bit characters; 
internal or HOLC/ 


SOLC character 
synchronization'; 
automatic 
sync inser- 


tion; even or odd parity. 


Asynchronous 
- 
5-8 bit characters; 
break character 


generation; 
1, 1'12, or 2 stop bits; false start bit detec- 


tion; even or odd parity. 


Frequency 
(kHz) 
Baud Rate (Hz) 


(Software 
Selectable) 
Synchronous 
Asynchronous 


Reference: 
1.23 MHz 
.;.1 
.;.1 
.;.6 
.;.32 
.;.64 


615. 
615,000 
615,000 
I 
38,400 
19,200 
9,600 


307. 
307,000 
307,000 
19,200 
9,600 
4,800 


154. 
154,000 
154,000 
9,600 
4,800 
2,400 


76.8 
76,800 
76,800 
4,800 
2,400 
1,200 
38.4 
38,400 
38,400 
2,400 
1,200 
600 


19.2 
19,200 
19,200 
1,200 
600 
300 


9.6 
9,600 
9,600 
600 
300 
150 


4.8 
4,800 
4,800 
300 
150 
75 
2.4 
2,400 
2,400 
150 
75 
- 
1.2 
1,200 
1,200 
75 
- 
- 
0.6 
600 
600 
- 
- 
- 


Input Frequencies 
- 
1.23 
MHz 
± 0.1 % or 3.00 
MHz 
± 0.1 % (Jumper 
Selectable) 


Single Timer/Counter 
Dual Timer/Counter 


Function 
(two timers cascaded) 


. 
Min 
Max 
Min 
Max 


Real-time 
interrupt 
667 ns 
53.3 ms 
1.33 p's 
58.2 
min 


Programmable 
one-shot 
667 ns 
53.3 ms 
1.33 p's 
58.2 min 


Rate generator 
18.8 Hz 
1.50 MHz 
0.000286 
Hz 
750 kHz 


Square-wave 
rate generator 
18.8 Hz 
1.50 MHz 
0.000286 
Hz 
750 kHz 


Software 
triggered 
strobe 
667 ns 
53.3 ms 
1.33 p's 
58.2 
min 


Hardware 
triggered 
strobe 
667 ns 
53.3 ms 
1.33 P.s 
58.2 min 


Event 
counter 
- 
8.0 MHz 
- 
- 


INTERFACES 


MUL TIBUS@- 
All 
signals 
TTL 
compatible 


iSBX™ Bus - 
All signals 
TTL 
compatible 


iLBXTMBus - 
All 
signals 
TTL 
compatible 


Serial I/O - 
Channel 
A: RS232C/RS422 
compatible, 


configurable 
as a data 
set or data 
terminal; 
Channel 
B: 


RS232C 
compatible, 
configured 
as data 
set 


Timer - 
All signals 
TTL 
compatible 


Interrupt 
Requests 
- 
All TTL 
compatible 


Interface 
Double-Sided 
Centers 
Mating 
Pins (qty.) 
(in.) 
Connectors 


MULTIBUS'" 
System 
86 
0.156 
Viking 
3KH43/9AMK12 
Wire Wrap 


iSBXTM Bus - 
8-Bit Data 
36 
0.1 
iSBXTM 960-5 


16-Bit Data 
44 
0.1 
iSBXTM 961-5 


iLBXTM Bus 
60 
0.1 
Kelam 
RF30-2803-5 


or 


T&B Ansley 
A3020 


(609-6026 
modified) 


Parallel 
110 
26 
0.1 
3M 3462-0001 
Flat 
or 
AMP 88106-' 
Flat 


Serial 
110 
26 
0.1 
3M 3462-0001 
Flat 


or 


AMP 88106-1 
Flat 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-State 
16 


Address 
Tri-State 
16 


Commands 
Tri-State 
32 


Bus Control 
Open 
Collector 
20 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-State 
9 


Address 
Tri-State 
20 


Commands 
Tri-State 
8 


Bus Control 
TTL 
8 


Physical Characteristics 


Width - 
12.00 in. (30.48 em) 


Height - 
6.75 in. (17.15 em) 


Electrical Characteristics 


DC Power Requirements 
- 
+5V, 7.0A; + 12V, 50 mA; 


-12V, 
50 mA 


Environmental Characteristics 


Operating 
Temperature 
- 
O°C to 55°C 


Relative 
Humidity 
- 
to 90% (without 
condensation) 


Reference Manual 


145439-001 
- 
iSBC 286/10 
Single 
Board Computer 


Design Guide (NOT SUPPLIED) 


Part Number 
Description 


SBC 286/10 
Single Board Computer 


inter 


iSBC®88/45 
ADVANCED 
DATA COMMUNICATIONS 
PROCESSOR BOARD 


• Three HDLC/SDLC halflfull·duplex 
communication 
channels 
- 
optional 
ASYNC/SYNC 
on two channels 


• Supports 
RS232C (including 
modem 
support), 
CCITT V.24, or RS422A1449 
interfaces 


• On-board DMA supports 
800K baud 
operation 


• Self-clocking 
NRZI SDLC loop data 
link interface 


- 
point-to-point 


- 
multidrop 


• Software 
programmable 
baud rate 
generation 


• iAPX 88/10 (8088-2) Microprocessor 


operates 
at 8 MHz 


• iSBC® 337 Numeric 
Data Processor 


option 
supported 


• 16K bytes static 
RAM (12K bytes 


dual-ported) 


• Four 28-pin JEDEC sites for 
EPROM/RAM expansion; 
four additional 


28-pin JEDEC sites added with iSBC® 
341 board 


• MUL TIBUS® interface 
supports 
Multimaster 
configuration 


The iSBC 88/45 Advanced 
Data Communications 
Processor 
(ADCP) Board adds 8 MHz, iAPX 88/10 (8088-2) 


8-bit microprocessor-based 
communications 
flexibility 
to the Intel line of OEM microcomputer 
systems. 


The iSBC 88/45 ADCP board offers 
asynchronous, 
synchronous, 
SDLC, and HDLC serial 
interfaces 
for 


gateway 
networking 
or general 
purpose 
solutions. 
The iSBC 88/45 ADCP board provides 
the CPU, system 


clock, 
EPROM/RAM, 
serial I/O ports, priority 
interrupt 
logic, and programmable 
timers 
to facilitate 
higher- 
level application 
solutions. 


The following 
are trademarks 
of 
Intel 
Corporation 
and may be used 
only 
to descnbe 
Inter 
products: 
Intel, 
CREDIT, 
Index, 
Insite. 
Inlellee, 
library 
Manager, 
Megachassis, 


Micromap, 
MUlTJBUS, 
PROMPT, 
UPI, ,IIScope, Promware, 
MeS, 
ICE. iRMX, iSBC, iSBX, MUl TlMODUlE 
and iCS. Intel Corporation 
assumes 
no responsibility 
for the use of any 


circuitry 
other than circuitry 
embodied 
in an Inlel product. 
No other circuit 
palent 
licenses 
are implied. 


© INTELCORPOAATION, 
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inter 


Three Communication 
Channels 


Three programmable 
HOLC/SOLC 
serial 
interfaces 


are provided 
on the 
iSBC 88/45 AOCP board. 
The 


SOLC interface 
is familiar 
to IBM system 
and ter- 
minal 
equipment 
users. 
The 
HOLC 
interface 
is 


known 
by users 
of CCITI's 
X.25 packet 
switching 


interface. 


One 
channel 
utilizes 
an Intel 
8273 
controller 
to 


manage 
the 
serial 
data 
transfers. 
Accepting 
the 


8-bit data bytes 
from 
the local 
bus, the 8273 con- 
troller 
translates 
the data into the HOLC/SOLC 
for- 


mat. The channel 
operates 
in half/full-duplex 
mode. 


In addition 
to 
the 
synchronous 
mode, 
the 
8273 


controller 
operates 
asynchronously 
with 
NRZI en- 


coded 
data which 
is found 
in systems 
such as the 


IBM 3650 Retail 
Store System. 
An SOLC loop con- 
figuration 
using 
iSBX 352 and iSBC 88/45 products 


is shown 
in Figure 
1. 


The two 
additional 
channels 
utilize 
the Intel 8274 


Multi-Protocol 
Serial Controller 
(MPSC). The MPSC 


provides 
two 
independent 
half/full-duplex 
serial 


channels 
which 
provide 
asynchronous, 
syn- 


chronous, 
H OLC or SOLC protocol 
operations. 
The 


sync and async 
protocol 
operations 
are commonly 


used to communicate 
with 
inexpensive 
terminals 


and systems. 


The three 
serial 
channels 
of the iSBC 88/45 AOCP 


board 
offer 
communications 
capability 
to manage 


a gateway 
application. 
The 
gateway 
application, 
as shown 
in Figure 
1, manages 
diverse 
protocol 
re- 


quirements 
for data movement 
between 
channels. 


Typical 
protocol 
management 
software 
layers 
im- 


plemented 
by the user include 
SNA terminal 
inter- 


faces 
to IBM systems. 
, 


For high-speed 
communications, 
one MPSC chan- 


nel has a OMA capacity 
to support 
an 800K baud 


. rate. The second 
channel 
attached 
to the M PSC is 


capable 
of 
simultaneous 
800K 
baud 
operation 


when 
configured 
with 
OMA capability, 
but is con- 


nected 
to an RS232C interface 
which 
is defined 
as 


20K baud maximum. 
Figure 2 shows 
an RS422A1449 


multidrop 
application 
which 
supports 
high-speed 


operation. 


Interfaces 
Supported 


The iSBC 88/45 AOCP board 
provides 
an excellent 


foundation 
to support 
these 
electrical 
and diverse 


software 
drivers 
protocol 
interfaces. 
The control 


lines, 
serial 
data lines, 
and signal 
ground 
lines are 


brought 
out to the three 
double-edge 
connectors. 


Figure 
3 shows 
the cable 
to connector 
construc- 


tion. 
Two 
connectors 
are 
pre-configured 
for 


RS422A/449. 
All 
three 
channels 
are configurab)e 


for 
RS232C/CCITT 
V.24 
interfaces 
as 
shown 
in 


Table 
1. 


Table 
1. iSBC® 88/45 Supported 
Configurations 


Synchronous 
Asynchronous 


Connection 
Modem 
Direct 
Modem" 
Direct 


point-to-point 
X·· 
X 
X 
X 


multidrop 
X 
X 
X 
X 


loop 
N.A. 
N.A. 
C 
C 


(only) 
(only) . 


• Modem should not respond to break. 


•• Channels A, B, and C denoted by X. 


I,iSBX" 35\ I 
I iSBX" 352 I 


_I 
__ 
'"""T"T'_ 


TT 


SO 


RT 


ISBC" 
88145 
BOARO 
RO 


TR 


OM 
I 
I 
CONNECTOR 
CONNECTOR 
J1 
J1 
TR 
OM 
SO 
TT 
RO 
RT 
TR 
OM 
SO 
TT 
RO 
RT 


iSBCl88J45 
iSO<:-88145 
BOARD 
BOARD 


SLAVE 
A 
SLAVE 
B 


NOTE: The last slave device in the system must contain termination 
resistors on all signal lines received by the slave board. 


The master device contains bias resistors on all signal lines. 


Self Clocking 
Point·To·Point 
Interface 


The iSBC 88/45 ADCP board 
is used in an asyn- 


chronous 
mode 
interface 
when 
configured 
as 
shown 
in Figure 4. The point-to-point 
RS232C ex- 
ample 
uses the self-clocking 
mode interface 
for 
NRZI 
encoding/decoding 
of 
data. 
The 
digital 
phase-lock 
loop allows 
operation 
of the interface 
in either half/duplex 
or full/duplex 
implementation 
with or without 
modems. 


hC 


TxO 


RTS 


ISSC" 
88145 CTS 
BOARD 
Rxe 


RxO 


OTR 
OSA 


Figure 4. Self-Clocking 
or Asynchronous 
Point-to- 
Point Modem 
interface 
Configuration 
Exampie 
- RS232C 


Synchronous 
Point·To·Point 
Interface 


Figure 5 shows a sychronous 
point-to-point 
mode 
of operation 
for the iSBC 88/45 ADCP board. This 
RS232C example uses a modem to generate the re- 
ceive clock 
for coordination 
of the data transfer. 


The iSBC 88/45 ADCP board generates 
the trans- 


mit sychronizing 
clock 
for synchronous 
transmis- 


sion. 


RTS 


CTS 


ISSC'!' 
88145 
TxO 
BOARD 
AxD 


OTR 


OSR 


Figure 5. Synchronous 
Point-to-Point 
Modem 
Interface 
Configuration 
Exampie 
- 
RS232C 


Central 
Processing 
Unit 


The central processor 
for the iSBC 88/45 Advanced 
Data Communications 
Processor 
board is Intel's 
8088 
microprocessor 
operating 
at 8 MHz. 
The 
microprocessor 
interface 
to other 
functions 
is 


illustrated 
in Figure 6. The microprocessor 
archi- 


tecture 
is designed 
to effectively 
execute 
the ap- 


plication 
and 
networking 
software 
written 
in 


higher-level 
languages. 


This architectural 
support includes 
four 16-bit byte 


addressable 
data 
registers, 
two 
16-bit 
memory 


base pointer 
registers 
and two 16-bit index regis- 


ters. These 
registers 
are addressable 
through 
24 


different 
operand 
addressing 
modes 
for compre- 


hensive memory addressing 
and for high-level 
lan- 


guage data structure 
manipulation. 


The stack-oriented 
architecture 
readily 
supports 


Intel's iRMX executives 
and iMMX multiprocessing 


software. 
Both 
software 
packages 
are designed 


for modular application 
programming. 
Facilitating 


the fast inter-module 
communications, 
the 4-byte 


instruction 
queue 
supports 
program 
constructs 


needed for real-time 
systems. 


Since programs 
are segmented 
between 
pure pro- 


cedure 
and data, 
four 
segment 
registers 
(code, 


staCk, data, extra) are available 
for addressing 
1 


megabyte 
of memory 
space. These registers 
con- 


tain the offset 
values used to address a 64K byte 


segment. 
The registers 
are controlled 
explicitly 


through 
program control 
or implicitly 
by high-level 


language 
functions 
and instructions. 


The real-time 
system 
software 
can also utilize the 


programmable 
timers as shown in Table 2 and var- 


ious 
interrupt 
control 
modes 
available 
on 
the 


ADCP board to have responsive 
and effective 
ap- 


plication 
solutions. 


Function 
Operation 


Interrupt on 
An interrupt 
is generated 
on 


Terminal 
terminal 
count 
being reached. 


Count 
This function is useful for gener- 
ation of real-time clocks. 


Rate 
Divide by N counter. Based on 


Generator 
the input clock period, the output 
pulse remains low until the count 
is expired. 


Square Wave 
Output remains high for one-half 


Generator 
the count, goes low for the re- 
mainder of the count. 


Software 
Output remains high until count 


Triggered 
expires, then goes low for one 


Strobe 
clock period. 


Numeric 
Data Processor 
Extension 


The 8088 instruction 
set includes 
8-bit and 16-bit 


signed 
and unsigned 
arithmetic 
operators 
for bi- 


nary, 
BCD, 
and 
unpacked 
ASCII 
data. 
For 
en· 


hanced 
numerics 
processing 
capability, 
the iSBC 


337 MULTIMODULE 
Numeric 
Data 
Processor 
ex- 


tends 
the 8088 architecture 
and data set'. 


The extended 
numerics 
capability 
includes 
over 


60 numeric 
instructions 
offering 
arithmetic, 
trigo- 


nometric, 
transcendental, 
logarithmic, 
and 
expo- 
nential 
instructions. 
Many 
math-oriented 
applica- 


tions 
utilize 
the 16-, 32-, and 64-bit 
integer, 
32- and 


64-bit 
floating 
point, 
18-digit 
packed 
BCD, 
and 


8o-bit temporary 
data types. 


16K Bytes Static Ram 


The iSBC 88/45 ADCP board contains 
16K bytes of 


high-speed 
static 
RAM, with 
12K bytes dual-ported 


which 
is addressable 
from 
other 
MUL TIBUS 
de- 


vices. 
When 
coupled 
with 
the 
high-speed 
DMA 


capability 
of the iSBC 88/45 ADCP board, the dual- 


ported 
memory 
provides 
effective 
data communi- 


cation 
buffers. 
The dual-ported 
memory 
is useful 


for interprocessor 
message 
transfers. 


, The iSSG337 board requires the iSSG88/45 AGDPboard be 


jumpered to provide 4 MHz operation. 


~~ 
~ 
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Interrupt Capability 


The 
iSBC 
88/45 
ADCP 
board 
provides 
nine 
vec- 


tored 
interrupt 
levels. 
The highest 
level is the NMI 


(Non-Maskable 
Interrupt) 
line. The additional 
eight 


interrupt 
levels 
are vectored 
via the 
Intel 
8259A 


Programmable 
Interrupt 
Controller 
(PIC). As shown 


in 
Table 
3, four 
priority 
processing 
modes 
are 


available 
to 
match 
interrupt 
servicing 
require- 


ments. 
These 
modes 
and priority 
assignments 
are 


dynamically 
configurable 
by the system 
software. 


Mode 
Operation 


Nested 
Interrupt request line priorities 
fixed; 


interrupt 0 is the highest and 7 is the 
lowest. 


Auto· 
The interrupt priority rotates; once an 


Rotating 
interrupt 
is serviced 
it becomes the 


lowest priority. 


Specific 
System software assigns lowest level 


Priority 
priority. The other levels are sequenced 
based on the level assigned. 


Polled 
System software examines priority in- 
terrupt via interrupt status register. 


STATIC 


.AM 
12K DUAl·PORT 
4K·LOCAl 


DUAL· 
PORT 


ACCESS 


CONTROL 


24·BlT 
SLAVE 


AODRESS 
DECODE 


intel 


Interrupt Request Generation 


Listed 
in Table 
4 are the 
devices 
and 
functions 


supported 
by interrupts 
on the 
iSBC 88/45 AOCP 


board. All interrupt 
signals 
are brought 
to the inter- 


rupt jumper 
matrix. 
Any of the 23 interrupt 
sources 


are strapped 
to the appropriate 
8259A PIC request 


level. The PIC resolves 
requests 
according 
to the 


software 
selected 
mode and, if the interrupt 
is un- 
masked, 
issues 
an interrupt 
to the CPU. 


EPROM/RAM Expansion 


In addition 
to the on-board 
RAM, 
the 
iSBC 
88/45 


AOCP 
board 
provides 
four 
28-pin 
JEOEC 
sockets 


for 
EPROM 
expansion. 
By using 
2764 
EPROMs, 
the board has 32K bytes of program 
storage. 
Three 


of the JEOEC standard 
sockets 
also support 
byte- 


wide 
static 
RAMs; 
using 
8K x 8 static 
RAMs 
pro- 


vides 
an additional 
24K bytes 
of RAM. 


Inserting 
the 
optional 
iSBC 
341 
MULTIMOOULE 


EPROM 
expansion 
board 
onto 
the 
iSBC 
88/45 


AOCP board provides 
four additional 
28-pin JEOEC 


sites. 
This 
expansion 
doubles 
the 
available 
pro- 


gram 
storage 
or extends 
the 
RAM 
capability 
by 


32K bytes. 


iSBX™ MULTIMODULET_M Expansion 


Two 
8-bit 
iSBX 
MULTIMOOULE 
connectors 
are 


provided 
on 
the 
iSBC 
88/45 
microcomputer. 
Through 
these 
cOAnectors, 
additional 
iSBX func- 
tions 
extend 
the 
I/O capability 
of the 
microcom- 


puter. The iSBX connectors 
provide 
the necessary 


signals 
to interface 
to the local 
bus. 


In 
addition 
to 
specialized 
or 
custom 
designed 


iSBX 
boards, 
the 
customer 
has a broad 
range 
of 


Intel 
iSBC 
MULTIMOOULEs 
available, 
including 


parallel 
I/O, analog 
I/O, IEEE 488 GPIB, floppy 
disk, 


magnetic 
bubbles, 
video, 
and serial 
I/O boards. 


The serial 
I/O MULTIMOOULE 
boards 
include 
the 


iSBX 
351 (one 
ASYNC/SYNC 
serial 
channel) 
and 
the 
iSBX 
352 
(one 
HOLC/SOLC 
serial 
channel) 


boards. 
Adding 
two 
iSBX 
352 
MUL TIMOOULE 


boards 
to the iSBC 88/45 AOCP provides 
a total 
of 


five HOLC/SOLC 
channels. 


OVERVIEW 


The MULTIBUS 
system 
is Intel's 
industry 
standard 


microcomputer 
bus 
structure. 
Both 
8- and 
16-bit 


single 
board 
computers 
are 
supported 
on 
the 


MULTIBUS 
structure 
with 
24 address 
and 16 data 


lines. 
In addition 
to 
expanding 
functions 
con- 


tained 
on a single 
board 
computer 
(e.g., memory 


and 
digital 
I/O), the 
MUL TIBUS 
structure 
allows 


very 
powerful 
distributed 
processing 
configura- 


tions 
with 
multiple 
processors, 
intelligent 
slaves, 


and peripheral 
boards. 


Multimaster Capability 


The 
iSBC 
88/45 
AOCP 
board 
provides 
full 


MULTIBUS 
arbitration 
control 
logic. 
This 
control 


Device 
Function 
No.-of 
Interrupts 


MULTIBUS~ Interface 
Select 1 interrupt 
from MULTIBUS~ resident peripherals 
or other 
8 


CPU boards 


8273 HOLC/SOLC 
Transmit buffer empty and receive buller full 
2 
Controller 


8274 HOLC/SOLC 
Software examines register for status of communication 
operation 
1 
SYNC/ASYNC Controller 


8254-Timer 
Counter 2 of both PIT devices 
2 


iSBXTMConnectors 
Function determined 
by iSBXTMMULTIMOOULETM Board (2 inter- 
4 
rupts per socket) 


Bus Fail Safe Timer 
Indicates 
MULTIBUS~ addressed 
device 
has not responded 
to 
1 
command within 4 msec 


Power Line Clock 
Source of 60 MHz signal from power supply 
1 


Bus Flag Interrupt 
Flag interrupt 
in byte location 
1000H signals board reset or data 
2 
handling request 


iSB~ 
337 Board 
Numeric Oata Processor generated status information 
1 


8237A-5 
Signals end of 8237 OMA operation 
1 


inter 


logic 
allows 
up to three iSBC 88/45 ADCP boards 
or other bus masters, 
including 
iSBC 80 and iSBC 
86 family 
boards to share the system 
bus using a 
serial 
(daisy chain) 
priority 
scheme. 
By using 
an 
external 
parallel 
priority 
decoder, 
the MUL TIBUS 
system 
bus 
could 
be 
shared 
among 
sixteen 
masters. 


The Intel standard 
MULTI BUS Interprocessor 
Pro- 
tocol 
(MIP) software, 
implemented 
as the 
Intel 
iMMX800 
package for iRMX80, iRMX86, and iRMX 
88 Real-Time 
Executives, 
fully 
supports 
multiple 
8-and 16-bit distributed 
processor 
functions. 
The 
software 
manages 
the message 
passing 
protocol 
between 
microprocessors. 


System Development Capabilities 


The application 
development 
cycle 
for an iSBC 
88/45 
ADCP 
board 
is 
reduced 
and 
simplified 
through 
the usage of several Intel tools. The tools 
include 
the Intellec 
Series 
Microcomputer 
Devel- 
opment 
System, 
the 
ICE-88 In-Circuit 
Emulator, 
the iSBC 957B debug 
monitor 
software, 
and the 


iRMX 86 and iRMX 88 run-time 
support 
packages. 


The Intellec 
Series 
Microcomputer 
Development 
System 
offers 
a complete 
development 
environ- 
ment for the iSBC 88/45 software. 
In addition 
to the 
operating 
system, assembler, 
utilities 
and applica- 


tion debugger 
features 
provided 
with the system, 


the 
user 
optionally 
can 
utilize 
higher-level 
lan- 
guages 
like PUM, PASCAL, and FORTRAN. 


The ICE-88 In-Circuit 
Emulator 
provides 
a link be- 
tween 
the 
Intellec 
system 
and the 
target 
iSBC 
88/45-based 
system 
for code 
loading 
and execu- 
tion. 
The 
ICE-88 package 
assists 
the 
developer 


with 
the debugging 
and system 
integrating 
pro- 
cesses. 


Run-Time Building Blocks 


Intel 
offers 
run-time 
foundation 
software 
to sup- 


port applications 
which 
range from 
general 
pur- 
pose to high-performance 
solutions. 
The iRMX 88 
Real-time Multitasking 
Executive 
provides 
a multi- 


tasking 
structure 
which 
includes 
task scheduling, 


task management, 
intertask 
communications, 
and 
interrupt 
servicing 
for high-performance 
applica- 
tions. 
The highly 
configurable 
modules 
make the 
system 
tailoring 
job easier whether 
one uses the 


compact 
executive 
or the complete 
executive 
with 


its variety of peripheral 
devices 
supported. 


The iRMX 86 Operating 
System 
provides 
a very 


rich set of features 
and options 
to support 
sophis- 


ticated 
applications 
solutions. 
In addition 
to sup- 


porting 
real-time 
requirements, 
the iRMX 86 Oper- 


ating 
System 
has 
a powerful, 
but 
easy-to-use 


human interface. 
When added to the sophisticated 


I/O system, the iRMX 86 Operating 
System is readi- 


ly extended 
to support 
assembler, 
PUM, PASCAL, 


and 
FORTRAN 
software 
development 
environ- 


ments. The modular 
building 
block software 
lends 


itself 
well to customized 
application 
solutions. 


Word Size 


Instruction 
- 
8, 16,24, or 32 bits 


Data - 
8 or 16 bits 


System Clock 


8 MHz - 
±0.1% 


NOTE: Jumper selectable for 4 MHz operation with iSBC 337 


Numeric Data Processor module or ICE-88 product. 


Cycle Time 


Basic Instruction 
Cycle at 8.00 MHz - 
1.25 ",see, 
250 nsec (assumes 
instruction 
in the queue) 


NOTE: Basic instruction cycle is defined as the fastest instruc· 


tion time (i.e., two clock cycles). 


Memory Cycle Time 


RAM - 
500 nsec (no wait states) 


EPROM - 
jumper selectable 
from 500 nsec to 625 


nsec. 


K Bytes 
Hex Address 


Range 


16 (total) 
0OOO-3FFF 


12 (dual-ported) 
1000-3FFF 


• Four iSBC 88/45 EPROM sockets support JEDEC 24/28·pin 


standard EPROMs and RAMs (3 sockets); iSSC 341 (4 sockets) 


Temperature 
- 
0-55 ·C, free moving air across the 


base board and MUL T1MODULE board 


Humidity 
- 
90%, non-condensing 


Physical Characteristics 


Width 
- 
30.48 cm (12.00 in) 


Length 
- 
17.15 cm (6.75 in) 


Height 
1.50 em (0.59 in) 


Weight 
6.20 gm (22 oz) 


Device 
Total 
Hex Address 


K Bytes 
Range 


2716 
8 
FEOOO·FFFFF 


2732A 
16 
FCOOO·FFFFF 


2764 
32 
F8000·FFFFF 


27128 
64 
FOOOO·FFFFF 


With 
optional 
iSBC<!J341 MULTIMODULfTM 
EPROM- 


Device 
Total 
Hex Address 
K Bytes 
Range 


2716 
16 
FCOOO·FFFFF 


2732A 
32 
F8000·FFFFF 


2764 
64 
FOOOO·FFFFF 


27128 
128 
EOOOO·FFFFF 


• Four iSSC 88145EPROMsockets support JEDEC24/28·pin 


standard EPROMsand RAMs(3 sockets); iSSC 341sockets 
also support EPROMsand RAMs. 


Interfaces 


iSBXTM Bus - 
All signals 
TTL compatible 


Serial 
RS232C Signals 
- 


CTS 
CLEAR 
TO SEND 
DSR 
DATA SET READY 
DTE TXC 
TRANSMIT 
CLOCK 
DTR 
DATA TERMINAL 
READY 


FG 
FRAME 
GROUND 
RTS 
REQUEST 
TO SEND 


RXC 
RECEIVE 
CLOCK 
RXD 
RECEIVE 
DATA 
SG 
SIGNAL 
GROUND 
TXD 
TRANSMIT 
DATA 


Serial 
RS422A1449 Signals 
- 


CS 
CLEAR 
TO SEND 
DM 
DATA 
MODE 


RC 
RECEIVE 
COMMON 


RD 
RECEIVE 
DATA 
RS 
REQUEST 
TO SEND 


RT 
RECEIVE 
TIMING 
SC 
SEND COMMON 
SD 
SEND 
DATA 


SG 
SIGNAL 
GROUND 


TR 
TERMINAL 
READY 


TT 
TERMINAL 
TIMING 


Electrical 
Characteristics 


DC Power 
Dissipation 
- 
28.3 Watts 


DC Power 
Requirements 
- 


Current 
Requirements 


Configuration 
(all voltages 
± 5%) 


+5V 
+12V 
.,..12V 


without 
EPROM' 
5.1A 
20mA 
20 mA 


with 8K EPROM 
+ 0.14A 
(using 2716) 
- 
- 


with 16K EPROM 
+0.20A 
- 
- 
(using2732A) 


with 32K EPROM 
+0.24A 
(using 2764) 
- 
- 


with 64K EPROM 
+0.24A 
(using 27128) 
- 
- 


NOTE1: AS SHIPPED- no EPROMsin sockets, no iSSC 341 


module. Configuration includes terminators for two 
RS422A1449and one RS232Cchannels. 


Channel 
Device 
Supported 
Max. Baud 


Interface 
Rate 


A 
8274' 
RS442AJ449 800K SOLC/HOLC 
RS232C 
125K Synchronous 


CCITIV.24 
50K Asynchronous 


B 
8274 
RS232C 
125K Synchronous2 


CCITIV.24 
50K Asynchronous 


C 
82733 
RS442AJ449 
64K SOLC/HOLC3 


RS232C 
9.6K 
SELF CLOCKING 


CCITIV.24 


NOTES: 
1. 8274supportsHDLC/SDLC/SYNC/ASYNCmultiprotocol 
2. ExceedRS232C/CCITTV.24ratingof 20Kbaud 
3. 8273supportsHDlC/SDlC 


8254 
Synchronous 
Asynchronous 


Timer 
Divide 
+16 
+32 
+64 


CountN 
K Baud 
K Baud 


10 
800 
50.0 
25.0 
12.5 


26 
300 
19.2 
9.6 
4.8 


31 
256 
16.1 
8.06 
4.03 


52 
154 
9.6 
4.8 
2.4 


104 
76.8 
4.8 
2.4 
1.2 


125 
64 
4.0 
2.0 
1.0 


143 
56 
3.5 
1.7 
.87 


167 
48 
3.0 
1.5 
.75 


417 
19.2 
- 
- 
- 


833 
9.6 
- 
- 
- 


EQUATION 
8,000,000 
500K 
250K 
125K 


N 
~ 
~ 
~ 


inter 


Interface 
Mode' 
MULTIMODULETM 
Cable 
Connector 
Edge Connector 


RS232C 
DTE 
26-pin4, 
3M-3462-0001 
3M2·3349/25 
25-pin6,3M·3482-1000 


RS232C 
DCE 
26-pin4, 
3M-3462-0001 
3M2·3349/25 
25·pin6,3M-3483·1000 


RS449 
DTE 
40-pin5, 
3M-3464-0001 
3M3·3349/37 
37·pin7,3M-3502·1000 


RS449 
DCE 
40-pin5, 
3M-3464-0001 
3M3_3349/37 
37-pin7,3M-3503-1000 


NOTES: 
1. DTE - 
Data Terminal Equipment mode (male connector); DCE - 
Data Circuit Equipment mode (female connector) requires line 
swaps. 


2. Cable is tapered at one end to fit the 3M-3462 connector. 
3. Cable is tapered to fit 3M-3464 connector. 
4. Pin 26 of the edge connector is not connected to the flat cable. 
5. Pins 38, 39, and 40 of the edge connector are not connected to the flat cable. 
6_ May be used with the cable housing 3M-3485-1000. 
7. Cable housing 3M-3485-4000may be used with the connector. 


Reference Manual 


143824 - 
iSBC 88/45 Advanced 
Data Communica· 


tions 
Processor 
Board 
Hardware 
Reference 
Man- 


ual (not supplied). 


Reference 
manuals 
may be ordered 
from any Intel 


sales representative, 
distributor 
office 
or from Intel 


Literature 
Department, 
3065 Bowers 
Avenue, 
Santa 


Clara, CA 95051 


Device 
Characteristic 
Qty 
Installed 


1488 
RS232C 
3 
1 


1489 
RS232C 
3 
1 


3486 
RS422A 
2 
2 


3487 
RS422A 
2 
2 


Part Number 


SBC 88/45 


Description 


8·bit 8088-based 
Single 
Board 
Computer 
with 
3 HDLC/SDLC 
serial 
channels 


intel~ 


iSBC 88/40 
MEASUREMENT 
AND CONTROL 
COMPUTER 


• High performance 5 MHz iAPX 88/10 
8-bit HMOS processor 


• 12-bit, 20 kHz analog-to-digital 
converter with programmable gain 
control 


• 16 differential/32 
single-ended analog 
input channels 


• Three iSBX MULTIMODULE 
connectors for analog, digital, and 
other I/O expansion 


• 4K bytes static RAM, expandable via 
iSBC 301 MULTIMODULE 
RAM to 8K 
bytes (1K byte dual-ported) 


• Four EPROM/E 2 PROM sockets for up 
to 64K bytes, expandable to 128K bytes 
with iSBC 341 expansion MULTI- 
MODULE 


• On-board 21-volt power supply for 
E2PROM modification 
under program 
control 


• MULTIBUS Intelligent Slave or 
Multimaster 


The Intel 
iSBC 88/40 Measurement 
and Control 
Computer 
is a member 
of Intel's 
large family 
of Single 


Board Computers 
that 
takes 
full 
advantage 
of .Intel's VLSI technology 
to provide 
an economical 
self- 


contained 
computer 
based solution 
for applications 
in the areas of process 
control 
and data acquisition. 


The on-board 
iAPX 88/10 processor 
with its powerful 
instruction 
set allows 
users of the iSBC 88/40 board 


to update 
process 
loops as much as 5-10 times 
faster 
than previously 
possible 
with other 8-bit micro- 


processors. 
For example, 
the high performance 
iSBC 88/40 can concurrently 
process 
and update 16 con- 


trol loops 
in less than 200 milliseconds 
using a traditional 
PID (Proportional-Integral-Derivative) 
control 


algorithm. 
The iSBC 88/40 board consists 
of a 16 differential/32 
single ended channel 
analog multiplexer 


with input protected 
circuits, 
AID converter, 
programmable 
central 
processing 
unit, dual port and private 


RAM, read only memory 
sockets, 
interrupt 
logic, 24 channels 
of parallel 
I/O, three programmable 
timers 


and MULTIBUS 
control 
logic on a single 
6.75 by 12.00-inch printed 
circuit 
card. The iSBC 88/40 board is 


capable 
of functioning 
by itself 
in a stand-alone 
system or as a multi master or intelligent 
slave in a large 


MULTIBUS 
system. 


Three Modes of Operation 


The iSBC 88/40 Measurement 
and Control Com: 


puter (MACC) is capable of operating 
in one of 


three 
modes: stand-alone 
controller, 
bus multi- 


master or intelligent 
slave. A block diagram of the 


iSBC 88/40 Measurement and Control Computer is 
shown in Figure 1. 


Stand·Alone 
Controller 


The iSSC 88/40 Measurement 
and Control Com- 


puter may function as a stand-alone §ingle board 
controller with CPU, memory and I/O elements on 
a single board. The on-board 4K bytes of RAM 
and up to 64K bytes of read only memory, as well 
as the analog-to-digital 
converter 
and program- 
able parallel I/O lines allow significant control and 
monitoring capabilities from a single board. 


Bus Multimaster 


In this mode of operation 
the iSBC 88/40 board 
may interface and control a wide variety of iSBC 
memory and I/O boards or even with additional 


J2 


ANALOG 
INPUTS 
PARALlel 
OIGITAlllO 


TO ICS 910, TO iCS 920, 930 
SIGNAL 
CONDITIONING/SCREW 


TERMINATION 
PANELS 


iSBC 88/40 boards or other single board computer 
masters or intelligent 
slaves. 


Intelligent 
Slave 


The iSBC 88/40 board can perform as an intelli- 
gent 
slave to any Intel 
8 or 16-bit MULTIBUS 


master CPU by not only offloading 
the master of 


the analog data collection, 
but it can also do a sig- 


nificant 
amount of pre-processing 
and decision 


making on its own. The distribution 
of processing 


tasks to intelligent 
slaves frees the system master 


to do other system functions. 
The dual port RAM 


with 
flag 
bytes 
for signalling 
allows 
the iSBC 


88/40 
board to process 
and store data without 


MULTIBUS memory or bus contention. 


Central 
Processing 
Unit 
The central 
processor 
unit for the iSSC 88/40 


board is a powerful 8-bit HMOS iAPX 88/10 micro- 
processor. The 22.5 sq. mil. chip contains approxi- 
mately 29,000 transistors and has a clock rate of 5 
MHz. The architecture 
includes four (4) address- 


able data registers and two (2) 16-bit memory base 
pointer registers and two (2) 16-bit index registers, 
all accessed by a total of 24 operand addressing 
modes for complex data handling and very flexible 
memory addressing. 


., 
I 
III 
L 
J 


iSBC341 


INSTRUCTIONSET - 
The iAPX 88/10 instruction 
repertoire includes variable length instruction for- 
mat (including double operand instructions), 8-bit 
and 16-bit signed and unsigned arithmetic oper- 
ators for binary, BCD and unpacked ASCII data, 
and iterative word and byte string manipulation 
functions. The instruction set of the iAPX 88/10 is 
a superset of the 8080A/8085A 
family and with 
available software tools, programs 'written for the 
8080A/8085Acan be easily converted and run on 
the iAPX 88/10 processor. Programs can also be 
run that are implemented on the iAPX 86/10 with 
little or no modification. 


ARCHITECTURALFEATURES- 
A 4-byte instruc- 
tion queue provides pre-fetching of sequential in- 
structions and can reduce the 1.04 msec minimum 
instruction cycle to 417 nsec for queued instruc- 
tions. The stack oriented architecture facilitates 
nested subroutines and co-routines, reentrant code 
and powerful interrupt handling. The memory ex- 
pansion capabilities offer a 1 megabyte·addressing 
range. The dynamic relocation scheme allows ease 
in segmentation of pure procedure and data for ef- 
ficient memory utilization. Four segment registers 
(code, stack, data, extra) contain program loaded 
offset values which are used to map 16-bit ad- 
dresses to 20-bit addresses. Each register maps 
64K by1es at a time and activation of a specific 
register is controlled explicitly by program control 
anc;jis also selected implicitly by specific functions 
and instructions. 


Bus Structure 
The iSBC 88/40 single board computer has three 
buses: 1) an internal bus for communicating with 
on-board 
memory, 
analog-to-digital 
converter, 
iSBX MULTIMODULES and I/O options; 
2) the 
MULTIBUS system bus for referencing additional 
memory and I/O options, and 3) the dual-port bus 
which allows access to RAM from the on-board 
CPU and the MULTIBUS system bus. Local (on- 
board) accesses do not require MULTIBUS com- 
munication, making the system bus available for 
use by other MULTIBUSmasters (i.e. DMA devices 
and other single board computers transferring to 
additional 
system memory). This feature allows 
true parallel processing in a multiprocessor 
en- 
vironment. In addition, the MULTIBUS interface 
can be used for system expansion through the use 
of other 8- and 16-bit iSBC computers, memory 
and I/O expansion boards. 


RAM Capabilities 


DUAL-PORT RAM - 
The dual-port RAM of the 
iSBC 88/40 board consists of 1K bytes of static 


RAM, implemented with Intel 2114Achips. The on- 
board base addess of this RAM is OOCOO(3K) nor- 
mally; it is relocated to 01COO(7K)when the iSBC 
301 MULTIMODULE RAM is added to the pro- 
tected RAM. The MULTIBUS port base address of 
the dual-port RAM can be jumpered to any 1K byte 
boundary in the 1M byte address space. The dual- 
port R~M can be accessed in a byte-wide fashion 
from the MULTIBUS system bus. When accessed 
from the MULT1BUS system bus, the dual-port 
RAM decode logic will 
generate INH1/ (Inhibit 


RAM) to allow dual-port RAM to overlay other 
system RAM. The dual-port control logic is de- 
signed to favor an on-board RAM access. If the 
dual-port is not currently performing a memory 
cycle for the MULT1BUSsytem port, only one wait 
state will be required. The on-board port may re- 
quire more than one wait state if the dual-port 
RAM was busy when the on-board cycle was re- 
quested. The LOCK prefix facility 
of the iAPX 


88/10assembly language will disallow system bus 
accesses to the dual-port RAM. In addition, the 
on-board port to the dual-port RAM can be locked 
by other compatible 
MULTIBUS masters, which 


allows 
true 
symmetric 
semaphore 
operation. 


When the board is functioning 
in the master 


mode, the LOCK prefix will additionally 
disable 


other masters from obtaining the system bus. 


PRIVATE RAM - 
In addition to the 1K byte dual- 


port RAM, there is a 3K byte section of private 
static RAM not accessible from the system bus. 
This RAM has a base address of 00000, and con- 
sists of three Intel 8185 RAM chips which are in- 
terfaced to the multiplexed address/data bus of 
the iAPX 88/10 microprocessor. Expansion of this 
private RAM from 3K to 7K bytes can be accom- 
plished by the addition of an iSBC 301 MULTI- 
MODULE RAM (4K bytes). When the 301 is added, 
protected RAM extends from 0 to 7K, and the base 
address of the dual-port RAM is relocated from 3K 
(OOCOO)to 7K (01COO).Ail 
protected 
RAM ac- 


cesses require one wait state. The private RAM 
resides on the local on-board bus, which elimi- 
nates contention problems between on-board ac- 
cesses to private RAM and system bus accesses 
to dual-port RAM. The private RAM can be battery 
backed (up to 16K bytes). 


Additional RAM can be added by utiliZing JEDEC- 
compatible static RAMs in the available EPROM 
sockets. 


Parallel I/O Interface 


The iSBC 88/40single board computer contains 24 
programmable 
parallel 
I/O lines 
implemented 


using the Intel 8255A Programmable Peripheral In- 


terface. The system software is used to confi!Jure 
the I/O lines in any combination of unidirectional 
input/output and bidirectional 
ports indicated in 


Table 1. There the I/O interface may be custom- 
ized to meet specific peripheral requirements. In 
order to take full advantage of the large number of 
possible I/O configurations, sockets are provided 
for interchangeable I/O line drivers and termi- 
nators. Port 2 can also accept TIL 
compatible 


peripheral drives, such as 75461/462,75471/472, 
etc. These are open collector, high voltage drivers 
(up to 55 volts) which can sink 300mA. Hence, the 
flexibility of the I/O interface is further enhanced 
by the capability of selecting the appropriate com- 
bination of optional line drivers and terminators to 
provide the required sink current, polarity, and 
drive/termination characteristics for each applica- 
tion. The 24 programmable I/O lines and signal 
ground lines are brought out to a 50-pin edge con- 
nector that mates with flat, woven, or round cable. 
This edge connector is also compatible with the 
Intel iCS 920 Digital I/O and iCS 930 AC Signal 
Conditioning/Termination 
Panels, for field wiring, 


optical isolation and high power (up to 3 amp) 
power drive. 


EPROM Capabilities 
Four (4) 28-pin sockets are provided for the use of 
Intel 2716s, 2732s, 2764s, 27128s, future JEDEC- 
compatible 128K and 256K bit EPROMs and their 
respective ROMs. When using 27128s the on- 
board EPROM capacity is 64K bytes. Read only 
memory expansion is available through the use of 
the iSBC 341 EPROM/ROM memory expansion 
MULTIMODULE. When the iSBC 341 is used an 
additional 
four (4) EPROM sockets are made 


available, for a total iSBC 88/40 board capacity of 
128K bytes EPROM with Intel 27128s. 


E2pROM Capabilities 


The four 28-pin sockets can also accommodate In- 
tel 2816 E2pROMs,for dynamic storage of control 
loop setpoints, conversion parameters, or other 
data (or programs) that change periodically but 
must be kept in nonvolatile storage. To give the 
user dynamic control of this nonvolatile memory, 
the iSBC 88/40 board also contains an on-board 
DC to DC converter which under program control 
will furnish the voltage necessary for modifying 
the contents of Intel 2816/2815E2pROMs. 


Timing Logic 
The iSBC 88/40board provides an 8253-5Program- 
mable Interval Timer, which contains three in- 
dependent, 
programmable 
16-bit 
timers/event 


counters. All three of these counters are available 
to generate time intervals or event counts under 
software 
control. 
The 
outputs 
of 
the 
three 


counters may be independently routed to the in- 
terrupt matrix. The inputs and outputs of timers 0 
and 1 can be connected to parallel I/O lines on the 
J1 connector, where they replace 8255A port C 
lines. The third counter is also used for timing 
E2pROM write operations. 


Interrupt Capability 


The iSBC 88/40 board provides 9 vectored inter- 
rupt levels. The highest level is the NMI (Non- 
maskable Interrupt) line which is directly tied to 
the iAPX 88/10 CPU. This interrupt cannot be in- 
hibited by software and is typically used for sig- 
nalling catastrophic events (I.e.,power failure). On 
servicing this interrupt, program control will be 
implicitly 
transferred through 
location 
00008H. 


The Intel 8259A Programmable Interrupt 
Con- 


troller (PIC) provides vectoring for the next eight 
interrupt levels. As shown in Table 2, a selection 


Mode of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Latched 
& 
Latched 
& 
Latched 
Strobed 
Latched 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X' 


4 
X 
X 
X' 


NOTE: 


1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed input or a latched and 


strobed output 
port or port 1 is used as a bidirectional 
port. 


of four 
priority 
processing 
modes 
is available 
to 
the designer 
to match system 
requirements. 
Oper· 
ating 
mode 
and priority 
assignments 
may be reo 
configured 
dynamically 
via software 
at any time 
during 
system 
operation. 
The PIC accepts 
inter- 


rupt 
requests 
from 
the 
programmable 
parallel 
and/or 
iSBX interfaces, 
the programmable 
timers, 


the system 
bus, or directly 
from peripheral 
equip- 


ment. 
The PIC then 
determines 
which 
of the 
in· 


coming 
requests 
is of the highest 
priority, 
deter· 
mines 
whether 
this 
request 
is of higher 
priority 


than the level currently 
being serviced, 
and, if ap- 
propriate, 
issues 
an 
interrupt 
to 
the 
CPU. 
Any 
combination 
of interrupt 
levels 
may be masked, 
via software, 
by storing 
a single 
byte in the inter- 


rupt mask register 
of the PIC. The PIC generates 
a 


unique 
memory 
address 
for each 
interrupt 
level. 


These addresses 
are equally 
spaced 
at 4-byte 
in- 


tervals. 
This 
32-byte 
block 
may 
begin 
at 
any 
32-byte boundary 
in the lowest 
1K bytes of memo 
ory·, 
and 
contains 
unique 
instruction 
pointers 


and 
code 
segment 
offset 
values 
(for 
expanded 


memory 
operation) 
for each interrupt 
level. After 
acknowledging 
an interrupt 
and obtaining 
a de- 
vice 
identifier 
byte from 
the 8259A PIC, the CPU 
will store its status 
flags on the stack and execute 


an indirect 
CALL 
instruction 
through 
the vector 
location 
(derived 
from the device 
identifier) 
to the 
interrupt 
service 
routine. 


·NOTE: The first 32 vector locationsare reservedby Intel for 
dedicatedvectors. Userswho wish to maintaincompatibility 
with presentand future Intel products should not use these 
locationsfor user-definedvectoraddresses. 


Mode 


Fully nested 


Operation 


Interrupt request line priorities 
fixed 
at 0 as highest, 7 as lowest. 


Equal priority. Each level, after receiv- 
ing service, becomes the lowest prior- 
ity level until next interrupt occurs. 


System software assigns lowest pri- 
ority level. Priority of all other levels 
based in sequence 
numerically 
on 
this assignment. 


System software 
examines 
priority· 
encoded system interrupt status via 
interrupt status register. 


Specific 
priority 


INTERRUPT 
REQUEST 
GENERATION 
- 
Interrupt 


requests 
may 
originate 
from 
26 
sources. 
Two 


jumper 
selectable 
interrupt 
requests 
can be auto- 
matically 
generated 
by the programmable 
periph- 
eral interface 
when a byte of information 
is ready 


to be transferred 
to the CPU (I.e., input 
buffer 
is 


full) or a byte of information 
has been transferred 


to a peripheral 
device (I.e., output 
buffer 
is empty). 


A jumper 
selectable 
request 
can be generated 
by 


each of the 
programmable 
timers. 
An additional 


interrupt 
request 
line 
may 
be jumpered 
directly 


from 
the 
parallel 
I/O driver 
terminator 
section. 


Eight 
prioritized 
interrupt 
request 
lines 
allow 
tbe 


iSBC 88/40 board to recognize 
and service 
inter· 


rupts 
originating 
from 
peripheral 
boards 
inter- 


faced via the MULTIBUS 
system 
bus. The fail safe 


timer can be selected 
as an interrupt 
source. 
Also, 


interrupts 
are provided 
from the iSBX connectors 


(6), end-of·conversion, 
PFIN and from 
the 
power 


line clock. 


Power-Fail Control 


Control 
logic 
is also included 
to accept 
a power- 


fail interrupt 
in conjunction 
with the AC-Iow signal 


from 
the iSBC 635, iSBC 640, and iCS 645 Power 


Supply 
or equivalent. 


iSBX MUL TIMODULE 
Expansion 
Capabilities 


Three 
iSBX 
MUL TIMODULE 
connectors 
are pro- 


vided 
on the 
iSBC 
88/40 board. 
Up to 
three 
(3) 


single wide MULTIMODULE 
or one (1) double 
wide 


and one (1) single 
wide iSBX MULTI MODULE 
can 


be added 
to the iSBC 88/40 board. A wide variety 


of peripheral 
controllers, 
analog and digital 
expan- 


sion 
options 
are available. 
For more 
information 


on 
specific 
iSBX 
MUL TIMODULES 
consult 
the 


Intel 
OEM 
Microcomputer 
System 
Configuration 


Guide. 


Processing Expansion Capabilities 


The addition 
of a iSBC 337 Multimodule 
Numeric 


Data Processor 
offers 
high 
performance 
integer 


and floating 
point 
math functions 
to users of the 


iSBC 88/40 board. The iSBC 337 incorporates 
the 


Intel 
8087 
and 
because 
of 
the 
MULTI MODULE 


implementation, 
it 
allows 
on-board 
expansion 


directly 
on the iSBC 88/40 board, eliminating 
the 


need 
for 
additional 
boards 
for 
floating 
point 


requirements. 


MUL TIBUS Expansion 


Memory and I/O capacity 
may be expanded 
further 


and additional 
functions 
added using 
Intel MULTI- 


BUS compatible 
expansion 
boards. 
Memory 
may 


be expanded 
by adding 
user specified 
combina- 


tions 
of RAM boards, 
EPROM boards, 
or memory 


combination 
boards. Input/output 
capacity 
may be 


increased 
by adding 
digital 
I/O and 
analog 
I/O 


MULTIBUS 
expansion 
boards. 
Mass storage 
capa- 


bility 
may be acheived 
by adding 
single 
or double 


density 
diskette 
controllers, 
or 
hard 
disk 
con· 


trollers 
either 
through 
the 
use of 
expansion 


boards and iSBX MULTIMODULES. Modular ex- 
pandable backplanes and cardcages are available 
to support multiboard systems. 


NOTE: Certain system restrictions 
may be incurred by the in- 
clusion of some of the iSaC 80 family options in an iSaC 88140 
system. Consult the Intel OEM Microcomputer 
System Config- 
uration Guide for specific 
data. 


Analog Input Section 


The analog section of the iSBC 88/40 board reo 
ceives all control signals through the local bus to 
initiate channel selection, gain selection, sample 
and hold operation, and analog-to·digital conver- 
sion. See Figure 2. 


INPUT 
CAPACITY 
- 
32 separate analog signals 


may be randomly or sequentially 
sampled 
in 


single-ended mode with the 32 input multiplexers 
and a common ground. For noiser environments, 
differential 
input 
mode can be configured 
to 


achieve 16 separate differential signal inputs, or 
32 pseudo differential inputs. 


RESOLUTION 
- 
The analog section 
provides 


12-bit resolution with a successive approximation 
analog·to-digital converter. For bipolar operation 
(- 5 to + 5 or - 10to + 10volts) it provides 11bits 
plus sign. 


SPEED 
- 
The A-to-D converter conversion speed 


is 50 J.ls(20 kHz samples per second). Combined 
with 
the 
programming 
interface, 
maximum 


throughput via the local bus and into memory will 
be 55 microseconds per sample, or 18 kHz sam· 
pies per second, for a single channel, a random 
channel, or a sequential channel scan at a gain of 


HIGH 
IMPEDANCE 
BUFFER 


AMP 


16 CHANNEL 
INPUT 
MULTIPLEXER 


PROGRAMMABLE 
GAIN SelECT 
& OFFSET 
ADJUST 


ANALOG 
INPUT 


SIGNALS 


16 CHANNel 
INPUT 
MULTIPLEXER 


G~lg~~~-4 
•.' 


~ 
PSEUDO 
DIFFERENTIAL 
GROUND 


1,5 ms at a gain of 5, 250ms at a gain of 50,and 20 
ms at a gain of 250. A·to-D conversion is initiated 
via a programmed command from the iAPX 88/10 
central processor. Interrupt on end-of-conversion 
is a standard feature to ease programming and 
timing constraints. 


ACCURACY 
- 
High quality components are used 


to achieve 12 bits resolution 
and accuracy of 


0.035% full 
scale range 
± V2 
LSB. Offset 
is 


adjustable 
under program control 
to obtain 
a 


nominal ± 0.024% FSR±'12 LSB accuracy at any 
fixed 
temperature 
between 
O·C 
and 
60·C 
(gain= 1). See specifications 
for other gain ac- 


curacies. 


GAIN 
- 
To allow sampling of millivolt level sig- 


nals such as strain gauges and thermocouples, 
gain is made configurable via user program com- 
mands up to 250x (20 millivolts full scale input 
range). User can select gain ranges of 1 (5V), 5 
(1V),50(100mY),250(20mY)to match his applica- 
tion. 


OPERATIONAL 
DESCRIPTION 
- 
The iSBC 88/40 


single board computer addresses the analog-to- 
digital converter by executing IN or OUT instruc- 
tions to the port address. Analog-to-digital conver- 
sions can be programmed in either of two modes: 
1) start conversion and poll for end-of-conversion 
(EOC),or 2) start conversion and wait for interrupt 
at end of conversion. When the conversion is com- 
plete as signaled by one of the above techniques, 
INput instructions 
read two bytes (low and high 


bytes) containing the 12-bit data word as shown 
on the following page. 


Output 
Command 
- 
Select 
input 
channel 
and 
start conversion. 


GAIN 
CONNECTOR 
CHANNEL 
SELECT 


BIT POSITION 
7 
6 
4 
3 
2 
1 
0 


INPUT 
CHANNEL I 
01 I 
0' 
I 
J I 
C3 I 
C, I 
C1 I 
CO 


Input Data - 
Read converted data (low byte) or 
Read converted data (high byte). 


Offset Correction 
- 
At higher gains (X 50, x 250) 
the voltage offset tempco in the AID circuitry 
can 
sometimes 
cause unacceptable 
inaccuracies. 
To 


correct for this offset, one channel can be dedi- 
cated to be used as a refer.ence standard. This 
channel can be read from the program to deter· 


mine the amount of offset. The reading from this 
channel 
will 
then be subtracted 
from all other 


channel readings, in effect eliminating 
the offset 


tempco. 


System 
Software 
Development 


The development 
cycle of the iSSC 88/40 board 


may be significantly 
reduced using an Intel Intel· 


lee Microcomputer 
Development System with the 


optional 
iAPX 88/iAPX 86 Software Development 


package. 


The iAPX 88/iAPX 86 Software Development pack- 
age includes 
Intel's 
high-level programming 
Ian· 


guage, PUM 86. PUM 86 provides the capability to 
program in a natural, algorithmic 
language and 


eliminates 
the need to manage register usage or 


allocate memory. PUM 86 programs can be writ- 
ten in a much shorter time than assembly 
lan- 


guage programs for a given application. 


SPECIFICATIONS 


Word Size 


Instruction 
- 
8, 16, or 32 bits 


Data - 
8 bits 


Instruction 
Cycle Time 


417 nanoseconds 
for fastest executable 
instruc- 
tion (assumes instruction 
is in the queue). 1.04 
microseconds 
for fastest 
executable 
instruction 


(assumes instruction 
is not in the queue). 


Memory 
Capacity 


On-board ROM/EPROM/E'PROM 
Up to 64K by1es; user installed in 2K, 4K, 8K or 16K 
by1e increments or up to 128K if iSSC 341 MULTI- 
MODULE EPROM option installed. Up to 8K bytes 
of E2pROM 
using 
Intel 
2816s 
may be user· 


installed in increments of 2, 4 or 8K by1es. 


On·board RAM 
4K bytes or 8K bytes if the iSSC 301 MULTIMOD· 
ULE RAM is installed. Integrity maintained during 
power failure 
with 
user-furnished 
batteries. 
1K 
bytes are dual-ported. 


Off· board Expansion 
Up to 1 megabyte of user·specified 
combination 


of RAM, ROM, and EPROM. 


Memory Addressing 
On·board ROM/EPROM 
FEOOO-FFFFF(using 2716 EPROMs) 
FCOOO·FFFFF(using 2732 EPROMs) 
F8000-FFFFF (using 2764 EPROMs) 
FOOOO-FFFFF(using 27128 EPROMs) 


On·board ROM/EPROM (With 
iSSC 341 MULTI· 


MODULE EPROM option installed) 
FCOOO-FFFFF(using 2716 EPROMs) 
F8000-FFFFF (using 2732 EPROMs) 
FOOOO-FFFFF(using 2764 EPROMs) 
EOOOO-FFFFF(using 27128 EPROMs) 


On·board RAM (CPU Access) 
OOOOO-OOFFF 
00000-01 FFF (if iSSC 301 MULTIMODULE RAM 
option installed) 
On·board RAM 
Jumpers allow 1K bytes of RAM to act as slave 
RAM for access by another bus master. Address· 
ing may be set within 
any 1K boundary 
in the 


1-megabyte system address space. 
Slave RAM Access 
Average; 350 nanoseconds 


Interval 
Timer 


Output Frequencies - 


Dual Timers 


Function 
Single Timer 
(Two Timers 


Min. 
Max. 
Cascaded) 


Real-Time 
0.977 
p's 
64 ms 
69.9 minutes 


Interrupt 
maximum 


Interval 
Rate 
15.625Hz 
1024kHz 
0.00024Hz 


Generator 
minimum 
(Frequency) 


iAPX 88110 CPU Clock 


4.8 MHz ±0.1% 


110 Addressing 


All 
communications 
to 
parallel 
110 ports, 
iSBX 


bus, AID port, timers, 
and interrupt 
controller 
are 


via read and write 
commands 
from 
the on-board 


iAPX 88/10 CPU. 


Interface 
Compatability 


Parallel 
110 - 
24 programmable 
lines (8 lines per 


port); one port includes 
a bidirectional 
bus driver. 


IC sockets 
are included 
for user installation 
of line 


drivers 
and/or 
I/O terminators 
and/or 
peripheral 


drivers 
as required 
for interface 
ports. 


iSBX Bus Connectors 
- 
Three iSBX bus connec· 


tors 
are provided. 
These 
connectors 
accept 
8-bit 


iSBX MULTIMODULE 
boards. One set of the three 


iSBX 
MULTIMODULE 
connectors 
will 
accept 
a 


double 
wide 
iSBX MUL TIMODULE 
board. 


Interrupts 


iAPX 88/10 CPU includes 
a non·maskable 
in'terrupt 


(NMI). 
NMI 
interrupt 
is provided 
for catastrophic 


events 
such as power failure. 
The on·board 
8259A 


PIC provides 
8·bit identifier 
of interrupting 
device 


to CPU. CPU multiplies 
identifier 
by four to derive 


vector 
address. 
Jumpers 
select 
interrupts 
from 26 


sources 
without 
necessity 
of external 
hardware. 


PIC may be programmed 
to accommodate 
edge- 


sensitive 
or level·sensitive 
inputs. 


Analog 
Input 


16 differential 
(bipolar 
operation) 
or 
32 single· 
ended 
(unipolar 
operation). 


Full Scale Voltage 
Range - 
- 5 to + 5 volts 
(bi· 


polar), 0 to + 5 volts 
(unipolar). 


NOTE: Ranges of 0 to 10V and ± 10V achievable with externally 
supplied ± 15V power. 
Gain - 
Program selectable for gain of 1,5,50, 
or 250. 


Resolution 
- 
12 bits 
(11 bits 
plus 
sign 
for 
± 5, 
± 10 volts). 
Accuracy 
- 
Including 
noise and dynamic 
errors 


Gain 
25°C 


1 
±0.05% 
FSR" 


5 
± 0.075% 
FSR* 
50 
± 0.085% 
FSR* 
250 
±0.12% 
FSR* 


* NOTE: FSR = Full Scale Range ± V2 LSB. Figures are in percent 
of full scale reading. At any fixed temperature between O°C and 
60°C, the accuracy is adjustable to ± 0.05% of full scale. 


Gain TC (at gain = 1) - 
30 PPM (typical), 56 PPM (max) 


per degree centigrade, 
40 PPM at other gains. 


Offset 
TC - 
Gain 
Offset 
TC (typical) 


(in % of FSR/oC) 
1 
0.0018% 
5 
0.0036% 
50 
0.024% 


250 
0.12% 


Sample 
and Hold·sample 
Time - 
15,..s 


Aperature·hold 
Aperature 
Time - 
120 ns 


Input Overvoltage 
Protection 
- 
30 volts 


Input 
Impedance 
- 
20 megohms 
(min.) 


Conversion 
Speed - 
50,..s (max.) at gain = 1 


Common 
Mode Rejection 
Ratio - 
60 dB (min.) 


Physical 
Characteristics 


Width 
- 
30.48 cm (12.00 in.) 


Length 
- 
17.15 cm (6.75 in.) 


Height 
-1.78 
cm (0.7 in.) 


2.82 cm (1.13 in.) with 
iSBC Memory 
Ex· 


pansion, 
MULTIMODULES, 
iSBX Numer· 


ic 
Data 
Processor 
or 
iSBX 
MULTI· 


MODULES. 


Electrical 
Requirements 


Power Requirements 
(Maximum) 
- 


Config· 
+SV 
+SV Aux 
+12V 
-12V 


uration 
Typ 
Max 
Typ 
Max 
Typ 
Max 
Typ 
Max 


iSSC 
4 
5.5 
100 
150 
80 
120 
30 
40 
88/40'·2 


NOTES: 
1. The current 
requirement 
includes 
one worst 
case (active· 


standby) EPROM current. 


2. If + 5V Aux is supplied 
by the iSBC 88/40 
board, the total 


+ 5V current is the sum of the + 5V and the + 5V Aux. 


Environmental 
Requirements 


Operating 
Temperature 
- 
0° 
to 
55°C 
(32°C 
to 


131°F) with 200 Ifm air flow 
Relative 
Humidity 
- 
to 90% 
without 
condensa· 


tion 


Equipment 
Supplied 


The following 
are supplied 
with 
the 
iSBC 
88/40 


board: 
a. Schematic 
diagram 
b. Assembly 
drawing 


Reference 
Manuals 


124978·001 - 
iSBC 88/40 Measurement 
and Con· 


trol 
Computer 
Hardware 
Reference 
Manual 
(NOT 


SUPPLIED). 


Manuals 
may be ordered 
from an Intel sales repre· 


sentative, 
distributor 
office 
or from Intel Literature 


Department, 
3065 
Bowers 
Avenue, 
Santa 
Clara, 


California 
95051. 


Part Number 
ssc 88/40 
Description 


Measurement 
and Control 


Computer 


intel 


iSBC™ 88/25 
SINGLE 
BOARD COMPUTER 


• 8·bit 8088 Microprocessor 
operating 
at 5 MHz 


• One megabyte 
addressing 
range 


• Optional 
Numeric 
Data Processor 
with iSBC 337 MULTIMODULE™ 
Processor 


• 4K bytes of static 
RAM; expandable 
on·board 
to 16K bytes 


• Sockets 
for up to 64K bytes of JEDEC 
24/28-pin standard 
memory 
devices; 
expandable 
on-board 
to 128K bytes 


• Programmable 
synchronous/asynchro· 


nous RS232C compatible 
serial inter- 


face with software 
selectable 
baud 


rates 


• 24 programmable 
parallel 
110 lines 


• Two programmable 
16·bit BCD or binary 


timers/event 
counters 


• 9 Levels of vectored 
interrupt 
control, 


expandable 
to 65 levels 


• MULTIBUS® interface 
for multimaster 


configurations 
and system 
expansion 


• Development 
support 
with Intel's 
iPDS, 


low cost Personal Development 
System, and EMV-88 Emulator 


The iSBC 88/25 Single 
Board Computer 
is a member of Intel's 
complete 
line of OEM microcomputer 
sys- 


tems which 
take full advantage 
of Intel's 
technology 
to provide 
economical, 
self-contained, 
computer- 


based solutions 
for OEM applications. 
The iSBC 88/25 board is a complete 
computer 
system on a single 


6.75 x 12.00-in. printed 
circuit 
card. The CPU, system 
clock, 
read/write 
memory, 
nonvolatile 
read only 


memory, 
I/O ports and drivers, serial communications 
interface, 
priority 
interrupt 
logic and programmable 


timers, 
all reside on the board. The large control 
storage 
capacity 
makes the iSBC 88/25 board ideally 


suited 
for control-oriented 
applications 
such as process 
control, 
instrumentation, 
industrial 
automation, 


and many others. 


The following 
are trademarks 
of tntet 
Corporation 
and may be used 
only 
10 describe 
Intel 
products: 
CREDIT, 
Index, 
Intel, 
Insite, 
lolellee, 
Library 
Manager, 
Megachassjs, 


Micromap, 
MULTISUS, 
P~OMPT, 
UPI,I4Scope, 
Promware, 
MeS, 
ICE, iRMX, iSBC, iS~X, 
MULTIM~OULE 
and ieS. Inlel Corporation 
assumes 
no responsibility 
for the use of any 
cirCUitry other than clrCulIry 
embodied 
in an Inlel product 
No other circuit 
patent 
licenses 
are Implied. 
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June 
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Central Processing Unit 


The central 
processor 
for the iSBC 88/25 board is 
Intel's 
8088 CPU operating 
at 5 MHz. The CPU ar- 


chitecture 
includes 
four 
16-bit 
byte addressable 


data 
registers, 
two 
16-bit 
memory 
base 
pointer 
registers 
and 
two 
16-bit 
index 
registers, 
all ac- 
cessed by a total of 24 operand addressing 
modes 


for 
comprehensive 
memory 
addressing 
and 
for 
support 
of the data structures 
required 
for today's 
structured, 
high 
level 
languages, 
as 
well 
as 
assembly 
language. 


Instruction Set 


The 8088 instruction 
repertoire 
includes 
variable 


length 
instruction 
format 
(including 
double 
oper- 
and instructions), 
8-bit and 16-bit signed 
and un- 


signed 
arithmetic 
operators 
for binary, 
BCD and 


unpacked 
ASCII data, and iterative 
word and byte 


string 
manipulation 
functions. 


For enhanced 
numerics 
processing 
capability, 
the 
iSBC 337 MULTIMODULE 
Numeric 
Data Proces- 


sor extends 
the architecture 
and data set. Over 60 
numeric 
instructions 
offer 
arithmetic, 
trigono- 
metric, 
transcendental, 
logarithmic 
and exponen- 


tial instructions. 
Supported 
data types include 
16, 


32, and 64-bit 
integer, 
and 32 and 64-bit floating 
point, 
18-digit 
packed 
BCD and 80-bit temporary. 


Architectural 
Features 


A 4-byte 
instruction 
queue 
provides 
pre-fetching 
of sequential 
instructions 
and can reduce the 750 
nsec 
minimum 
instruction 
cycle 
to 250 nsec for 
queued 
instructions. 
The stack-oriented 
architec- 


ture 
readily 
supports 
modular 
programming 
by 
facilitating 
fast, simple, 
inter-module 
communica- 
tion, 
and other 
programming 
constructs 
needed 
for asynchronous 
real-time 
systems. 
The memory 
expansion 
capabilities 
offer 
a 1 megabyte 
ad- 
dressing 
range. The dynamic 
relocation 
scheme 
allows 
ease 
in segmentation 
of pure 
procedure 
and 
data 
for 
efficient 
memory 
utilization. 
Four 
segment 
registers 
(code, 
stack, 
data, extra) 
con- 
tain program 
loaded offset 
values which 
are used 
to map 16-bit addresses 
to 20-bit addresses. 
Each 
register 
maps 64K bytes at a time and activation 
of 
a specific 
register 
is controlled 
explicitly 
by pro-· 


gram 
control 
and 
is also 
selected 
implicitly 
by 
specific 
functions 
and instructions. 
All Intel'" 
lan- 


guages 
support 
the extended 
memory 
capability, 


relieving 
the programmer 
of managing 
the mega- 
byte memory 
space, yet allowing 
explicit 
control 
when necessary. 


inter 


Memory Configuration 


The iSBC 88/25 microcomputer 
contains 
4K bytes 
of high-speed 
static 
RAM on-board. 
In addition, 
the on-board 
RAM may be expanded 
to 12K bytes 
via 
the 
iSBC 
302 8K 
byte 
RAM 
module 
which 
mounts 
on the iSBC 88/25 board and then to 16K 
bytes 
by 
adding 
two 
4K x 4 
RAM 
devices 
in 
sockets 
on the 
iSBC 
302 module. 
All 
on-board 
RAM is accessed 
by the 8088 CPU with 
no wait 
states, 
yielding 
a memory 
cycle 
time of 800 nsec. 


In addition 
to the on-board 
RAM, the iSBC 88/25 
board 
has four 28-pin 
sockets, 
configured 
to ac- 
cept 
JEDEC 24/28-pin 
standard 
memory 
devices. 


Up to 
64K 
bytes 
of 
EPROM 
are 
supported 
in 
16K-byte 
increments 
with 
Intel 
27128 
EPROMs. 
The iSBC 88/25 board is also compatible 
with the 
2716,2732, 
and 2764 EPROMs allowing 
a capacity 
of 
8K, 
16K, and 
32K 
bytes, 
respectively. 
Other 
JEDEC 
standard 
pinout 
devices 
are 
also 
sup- 
ported, 
including 
byte-wide 
static 
and integrated 
RAMs. 


With the addition 
of the iSBC 341 MULTIMODULE 
EPROM option, 
the 
on-board 
capacity 
for these 
devices 
is doubled, 
providing 
up to 128K bytes of 
EPROM capacity 
on-board. 


Parallel I/O Interface 


The iSBC 88/25 Single 
Board Computer 
contains 
24 programmable 
parallel 
I/O lines 
implemented 
using 
the 
Intel 
8255A 
Programmable 
Peripheral 
Interface. 
The system 
software 
is used to config- 
ure the I/O lines 
in any combination 
of unidirec- 
tional 
input/output 
and 
bidirectional 
ports 
indi- 
cated in Table 1. In order to take advantage 
of the 


large 
number 
of 
possible 
I/O 
configurations, 


sockets 
are provided 
for interchangeable 
I/O line 


drivers 
and terminators, 
allowing 
the selection 
of 


the 
appropriate 
combination 
of 
optional 
line 


driver:> and terminators 
with the required 
drive/ter- 


mination 
characteristics. 
The 
24 programmable 


I/O lines and signal 
ground 
lines are brought 
out 


to a 50-pin edge connector. 


I 


A programmable 
communications 
interface 
using 


the Intel 8251A Universal 
Synchronous/Asynchro- 


nous 
Receiver/Transmitter 
(USART) is contained 


on the 
iSBC 88/25 board. 
A software 
selectable 


baud rate generator 
provides 
the USART with 
all 


common 
commu'nication 
frequencies. 
The mode 


of operation 
(I.e., synchronous 
or asynchronous), 


data format, 
control 
character 
format, 
parity, 
and 


baud rate are all under program control. 
The 8251A 


provides 
full duplex, 
double 
buffered 
transmit 
and 


receive 
capability. 
Parity, 
overrun, 
and 
framing 


error detection 
are all incorporated 
in the USART. 


The RS232C compatible 
interface 
on each board, 


in conjunction 
with 
the USART, provides 
a direct 


interface 
to 
RS232C compatible 
terminals, 
cas- 


settes, 
and asynchronous 
and synchronous 
mo- 


dems. 
The 
RS232C command 
lines, 
serial 
data 


lines and signal 
ground 
line are brought 
out to a 


26-pin 
edge 
connector. 


Programmable Timers 


The iSBC 88/25 board provides 
three independent, 


fully 
programmable 
16-bit 
interval 
timers/event 


counters 
utilizing 
the 
Intel 
8253 
Programmable 


Mode of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Control 
(qty) 
Bidirectional 
Latched 
& 
Latched 
Latched 
& 
Latched 
Strobed 
Strobed 
. 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
Xl 


4 
X 
X 
Xl 


NOTE: 
1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed input or a latched and 


strobed output port or port 1 is used as a bidirectional 
port. 


Interval 
Timer. 
Each 
counter 
is capable 
of oper- 
ating 
in either 
BCD or binary 
modes. 
Two of these 
timers/counters 
are available 
to the 
systems 
de- 
signer 
to generate 
accurate 
time 
intervals 
under 


software 
control. 
Routing 
for 
the 
outputs 
and 
gate/trigger 
inputs 
of 
two 
of 
these 
counters 
is 
jumper 
selectable. 
The outputs 
may 
be indepen- 
dently 
routed 
to 
the 
8259A 
Programmable 
Inter- 
rupt 
Controller 
and to the 
I/O terminators 
associ- 
ated with 
the 8255A to allow 
external 
devices 
or an 
8255A 
port 
to gate 
the 
timer 
or to count 
external 
events. 
The 
third 
interval 
timer 
in the 
8253 
pro- 
vides 
the 
programmable 
baud 
rate 
generator 
for 
the 
iSBC 
88/25 board 
RS232C 
USART 
serial 
port. 


The system 
software 
configures 
each 
timer 
inde- 


pendently 
to 
select 
the 
desired 
function. 
Seven 
functions 
are available 
as shown 
in Table 
2. The 


contents 
of each counter 
may be read at any time 
during 
system 
operation. 


Function 


Interrupt 
on 


terminal count 


Programmable 
one-shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When terminal count is reached, an 
interrupt 
request is generated. This 
function 
is 
extremely 
useful 
for 
generation 
of real-time clocks. 


Output goes low upon receipt of an 
external 
trigger 
edge or software 
command 
and returns 
high when 
terminal 
count 
is 
reached. 
This 
function 
is retriggerable. 


Divide 
by N counter. 
The output 
will 
go 
low 
for 
one 
input 
clock 
cycle, and the period from one low 
going pulse to the next is N times 
the input clock period. 


Output 
will 
remain high until one- 
half the count has been completed, 
and go low for the other half of the 
count. 


Output remains high until software 
loads 
count 
(N). 
N counts 
after 
count 
is loaded, output 
goes low 
for one input clock period. 


Output 
goes 
low 
for 
one 
clock 
period 
N counts 
after 
rising edge 
counter 
trigger 
input. The counter 
is retriggerable. 


On a jumper 
selectable 
basis, the 
clock input becomes an input from 
the external system. CPU may read 
the 
number 
of 
events 
occurring 
after 
the 
counter 
"window" 
has 
been enabled or an interrupt 
may 
be generated after N events occur 
in the system. 


iSBX MULTIMODULE 
On·Board 
Expansion 


Two 
8-bit 
iSBX 
MULTIMODULE 
connectors 
are 
provided 
on 
the 
iSBC 
88/25 
microcomputer. 


Through 
these 
connectors, 
additional 
on-board 
I/O 
functions 
may 
be 
added. 
iSBX 
MULTIMOD- 


ULES 
optimally 
support 
functions 
provided 
by 
VLSI 
peripheral 
components 
such 
as additional 
parallel 
and 
serial 
I/O, 
analog 
I/O, 
small 
mass 


storage 
device 
controllers 
(e.g., 
cassettes 
and 
floppy 
disks), 
and other 
custom 
interfaces 
to meet 
specific 
needs. 
By mounting 
directly 
on the single 
board 
computer, 
less 
interface 
logic, 
less 
power, 


simpler 
packaging, 
higher 
performance, 
and lower 
cost 
result 
when 
compared 
to other 
alternatives 
such 
as 
MULTIBUS 
form 
factor 
compatible 
boards. 
The 
iSBX 
connectors 
on the 
iSBC 
88/25 
provide 
all 
signals 
necessary 
to 
interface 
to the 
local 
on-board 
bus. A broad 
range 
of iSBX MUL TI- 


MODULE 
options 
are available 
in this 
family 
from 
Intel. Custom 
iSBX modules 
may also be designed 
for use on the 
iSBC 
88/25 board. 
An iSBX bus 
in- 


terface 
specification 
and 
iSBX 
connectors 
are 
available 
from 
Intel. 


MULTIBUS SYSTEM BUS AND 
MULTIMASTER CAPABILITIES 


Overview 


The 
MUL TIBUS 
system 
bus 
is 
Intel's 
industry 
standard 
microcomputer 
bus 
structure. 
Both 
8 
and 
16-bit 
single 
board 
computers 
are supported 
on the 
MUL TIBUS 
structure 
with 
24 address 
and 
16 
data 
lines. 
In 
its 
simplest 
application, 
the 
MUL TIBUS 
system 
bus allows 
expansion 
of func- 
tions 
already 
contained 
on 
a single 
board 
com- 


puter 
(e.g., memory 
and digital 
I/O). However, 
the 
MUL TIBUS 
structure 
also 
allows 
very 
powerful 
distributed 
processing 
configurations 
with 
multi- 
ple 
processors 
and 
intelligent 
slave 
I/O, 
and 
peripheral 
boards 
capable 
of 
solving 
the 
most 
demanding 
microcomputer 
applications. 
The 
MULTIBUS 
system 
bus is supported 
with 
a broad 
array 
of board 
level 
products, 
LSI interface 
com- 


ponents, 
detailed 
published 
specifications 
and 
application 
notes. 


Expansion Capabilities 


Memory 
and 
I/O capacity 
may 
be expanded 
and 
additional 
functions 
added 
using 
Intel 
MULTIBUS 
compatible 
expansion 
boards. 
Memory 
may 
be 
expanded 
by adding 
user specified 
combinations 


inter 


of RAM boards, 
EPROM boards, 
or combination 


boards. 
Input/output 
capacity 
may be added with 


digital 
I/O and analog 
I/O expansion 
boards. Mass 


storage 
capability 
may 
be 
achieved 
by adding 


single 
or double 
density 
diskette 
controllers, 
or 


hard disk 
controllers. 
Modular 
expandable 
back- 
planes 
and 
cardcages 
are available 
to 
support 


multiboard 
systems. 


Multimaster 
Capabilities 


For those 
applications 
requiring 
additional 
pro- 


cessing 
capacity 
and 
the 
benefits 
of 
multi- 


processing 
(i.e., several 
CPUs and/or 
controllers 


logically 
sharing 
system 
tasks through 
communi- 


cation 
of the system 
bus), the iSSC 88/25 board 


provides 
full 
MUl TISUS arbitration 
control 
logic. 
This control 
logic 
allows 
up to three 
iSSC 88/25 


boards 
or other 
bus masters, 
inciuding 
iSSC 80 


and iSSC 86 family 
MUlTISUS 
compatible 
single 


board computers 
to share the system 
bus using a 


serial (daisy chain) priority 
scheme 
and allows 
up 


to 16 masters 
to share the MUlTISUS 
system 
bus 


with an external 
parallel 
priority 
decoder. 
In addi- 


tion 
to the multiprocessing 
configurations 
made 


possible 
with 
multimaster 
capability, 
it also pro- 


vides 
a very efficient 
mechanism 
for all forms 
of 


DMA (Direct 
Memory 
Access) 
transfers. 


Interrupt Capability 


The iSSC 88/25 board 
provides 
9 vectored 
inter- 


rupt 
levels. 
The 
highest 
level 
is the 
NMI 
(Non- 
Maskable 
Interrupt) 
line which 
is directly 
tied 
to 


the 8088 CPU. This interrupt 
is typically 
used for 


signaling 
catastrophic 
events (e.g., power failure). 


The 
Intel 
8259A 
Programmable 
Interrupt 
Con- 


troller 
(PIC) provides 
control 
and vectoring 
for the 


next eight 
interrupt 
levels. As shown 
in Table 3, a 


selection 
of 
four 
priority 
processing 
modes 
is 


available 
for use in designing 
request 
processing 


configurations 
to match system 
requirements 
for 


efficient 
interrupt 
servicing 
with 
minimal 
laten- 


cies. 
Operating 
mode 
and 
priority 
assignments 


may be reconfigured 
dynamically 
via software 
at 


any time 
during 
system 
operation. 
The 
PIC ac- 


cepts 
interrupt 
requests 
from 
all 
on-board 
I/O 


resources 
and from 
the 
MUl TISUS system 
bus. 


The PIC then 
resolves 
requests 
according 
to the 


selected 
mode and, if appropriate, 
issues an inter- 


rupt 
to 
the 
CPU. Any 
combination 
of 
interrupt 


levels 
may be masked 
via software, 
by storing 
a 


single 
byte in the 
interrupt 
mask 
register 
of the 


PIC. 
In 
systems 
requiring 
additional 
interrupt 


levels, slave 8259A PICs may be interfaced 
via the 


MUl T1SUS system 
bus, 
to 
generate 
additional 


vector 
addresses, 
yielding 
a total 
of 65 unique 


interrupt 
levels. 


Mode 
Operation 


Fully nested 
Interrupt request line priorities fixed 
at 0 as highest, 7 as lowest. 


Auto-rotating 
Equal priority. Each level, after re- 
ceiving service, becomes the lowest 
priority level until next interrupt oc- 
curs. 


Specific 
System 
software 
assigns 
lowest 


priority 
priority 
level. Priority 
of all other 


levels based in sequence numeric- 
ally on this assignment. 


Polled 
System software examines priority- 
encoded system interrupt status via 
interrupt status register. 


Interrupt Request Generation 


Interrupt 
requests 
to 
be serviced 
by the 
iSSC 


88/25 board may originate 
from 24 sources. 
Table 


4 includes 
a list 
of devices 
and functions 
sup- 


ported 
by 
interrupts. 
All 
interrupt 
signals 
"are 


brought 
to the interrupt 
jumper 
matrix 
where any 


combination 
of interrupt 
sources 
may be strapped 


to the desired 
interrupt 
request 
level on the 8259A 


PIC or the NMI input 
to the CPU directly. 


Power·Faii Control and Auxiliary Power 


Control 
logic 
is also included 
to accept 
a power- 


fail interrupt 
in conjunction 
with the AC-Iow signal 


from the iSSC 635 and iSSC 640 Power Supply 
or 


equivalent, 
to initiate 
an orderly 
shut down of the 


system 
in the event of a power 
failure. 
Addition- 


ally, an active-low 
TTl compatible 
memory 
protect 


signal 
is brought 
out on the auxiliary 
connector 


which, 
when asserted, 
disables 
read/write 
access 


to RAM memory 
on the board. This 
input 
is pro- 


vided 
for the protection 
of RAM contents 
during 


system 
power-down 
sequences. 
An 
auxiliary 


power 
bus 
is 
also 
provided 
to 
allow 
separate 


power to RAM for systems 
requiring 
battery 
back- 


up of read/write 
memory. 
Selection 
of this 
auxil- 


iary RAM power 
bus is made via jump~rs 
on the 


board. 


System Development Capabilities 


The 
development 
cycle 
of 
iSSC 
88/25 products 


can 
be significantly 
reduced 
and 
simplified 
by 


using the Intellec 
Series 
Microcomputer 
Develop- 


ment 
Systems. 
The 
Assembler, 
locating 
Linker, 


Library 
Manager, 
Text Editor and System 
Monitor 


are all supported 
by the ISIS-II 
disk-based 
operat- 


ing 
system. 
To 
facilitate 
conversion 
of 
8080A/ 
8085A 
assembly 
language 
programs 
to run on the 
iSBC 88/25 
board, 
CONV-86 
is available 
under 
the 
ISIS·II 
operating 
system. 
The 
iSBC 
88/25 
board 
is 
also supported 
by Intel's 
iPDS, 
Personal 
Develop- 
ment 
System. 
This 
system 
provides 
low 
cost 
development 
support 
while 
at the 
same 
time 
pro- 
viding 
personal 
computer 
capability 
for 
the 
engineer. 


IN·CIRCUIT 
EMULATOR 


The ICE-88 
In-Circuit 
Emulator 
provides 
the neces- 
sary 
link 
between 
the 
software 
development 
en- 
vironment 
provided 
by the Intellec 
system 
and the 


"target" 
iSBC 88/25 
execution 
system. 
In addition 


to providing 
the mechanism 
for loading 
executable 


code 
and 
data 
into 
the 
iSBC 
88/25 
board, 
the 


ICE-88 
In-Circuit 
Emulator 
provides 
a sophisticated 


command 
set to assist 
in debugging 
software 
and 


final 
integration 
of the user hardware 
and software. 


The 
EMV-88 
Emulator, 
designed 
for 
8088-based 


product 
support 
on the 
iPDS, 
provides 
for a com· 


plete development 
solution 
at low cost. 


Intel's 
system's 
'implementation 
language, 


PUM-86, 
is also available 
as an Intellec 
Microcom· 


puter 
Development 
System 
option. 
PUM-86 
pro- 
vides 
the 
capability 
to 
program 
in 
algorithmic 


language 
and eliminates 
the need to manage 
reg- 


ister 
usage or allocate 
memory 
while 
still 
allowing 
explicit 
control 
of the 
system's 
resources 
when 


needed. 


Run-Time Support 


Intel 
also 
offers 
two 
run·time 
support 
packages; 


iRMX 
88 
Realtime 
Multitasking 
Executive 
and 


the iRMX 
86 Operating 
System. 
iRMX 88 is a sim- 


ple, 
highly 
configurable 
and 
efficient 
foundation 


for small, 
high 
performance 
applications. 
Its mul- 
titasking 
structure 
establishes 
a solid 
foundation 


for 
modular 
system 
design 
and 
provides 
task 


scheduling 
and management, 
intertask 
communi· 


cation 
and 
synchronization, 
and 
interrupt 
servic- 


ing for a variety 
of peripheral 
devices. 
Other 
con- 


figurable 
options 
include 
terminal 
handlers, 
disk 


file system, 
debuggers 
and other 
utilities. 
iRMX 86 


is a high 
functional 
operating 
system 
with 
a very 


rich 
set 
of 
features 
and 
options 
based 
on 
an 


object-oriented 
architecture. 
In addition 
to being 


modular 
and 
configurable, 
functions 
beyond 
the 


nucleus 
include 
a sophisticated 
file 
management 


and 
I/O system, 
and 
powerful 
human 
interface. 


Both 
packages 
are 
easily 
customized 
and 
ex· 


tended 
by the user to match 
unique 
requirements. 


Device 
Function 
Number 
of 


Interrupts 


MULTIBUS interface 
Requests from MULTIBUS resident peripherals or other CPU 
8; may be expanded to 


boards 
64 with 
slave 
8259A 


PIC's 
on 
MULTIBUS 


boards 


8255A Programmable 
Signals 
input 
buffer 
full or output 
buffer 
empty; also BUS 
3 


Peripheral Interface 
INTR OUT general purpose interrupt 
from driverlterminator 
sockets 


8251A USART 
Transmit 
buffer empty and receive buffer full 
2 


8253 Timers 
Timer 0, 1 outputs; 
function 
determined 
by timer mode 
2 


iSBX connectors 
Function 
determined 
by iSBX MULTIMODULE board 
4 


(2 per iSBX connector) 


Bus fail safe timer 
Indicates addressed MULTI BUS resident device has not reo 
1 


sponded to command within 6 msec 


Power fail interrupt 
Indicates AC power is not within 
tolerance 
1 


Power line clock 
Source of 120 Hz signal from power supply 
1 


External interrupt 
General purpose interrupt 
from parallel port J1 
. 
1 


connector 


iSBC 337 MULT1MODULE 
Indicates error or exception 
condition 
1 
Numeric 
Data Processor 
. 


inter 


Word Size 


INSTRUCTION 
- 
8, 16, 24, or 32 bits 


DATA 
- 
8 bits 


System 
Clock 


5.00 MHz or 4.17 MHz±0.1% 
(jumper 
selectable) 


NOTE: 4.17 MHz required with the optional iSBG337module. 


Cycle Time 


BASIC 
INSTRUCTION 
CYCLE 


At 5 MHz - 
1.2 p'sec 
- 
400 nsec 
(assumes 
instruction 
in the 
queue) 


NOTES: Basic instruction cycle is defined as the fast~st in· 
struction time (i.e., two clock cycles). 


Memory Cycle Time 


RAM - 
800 nsec 
(no wait 
states) 


EPROM 
- 
Jumper 
selectable 
from 
800 
nsec 
to 


1400 nsec 


Memory 
Capacity/Addressing 


ON·BOARD 
EPROM 


Device 
Total Capacity 
Address 
Range 


2716 
8K bytes 
FEOOO-FFFFFH 
2732 
16K bytes 
FCOOO-FFFFFH 
2764 
32K bytes 
F8000-FFFFFH 
27128 
64K bytes 
FOOOO-FFFFFH 


WITH 
iSBC 
341 MULTIMODULE 
EPROM 


Device 
Total 
Capacity 
Address 
Range 


2716 
16K bytes 
FCOOO-FFFFFH 
2732 
32K bytes 
F8000-FFFFFH 
2764 
64K bytes 
FOOOO-FFFFFH 
27128 
128K bytes 
EOOOO-FFFFFH 
NOTES: iSBG88/25EPROMsockets support JEDEG24/28·pin 
standard EPROMsand RAMs (2 sockets); iSBG 341 sockets 
also support E2pROMs. 


ON· BOARD 
RAM 


4K bytes 
- 
O-OFFFH 


WITH 
iSBC 302 MULTIMODULE 
RAM 


12K bytes 
- 
0-2FFFH 


WITH 
iSBC 302 MUL TIMODULE 
BOARD 
AND 
TWO 4K x 4 RAM CHIPS 
16K bytes 
- 
0-3FFFH 


I/O Capacity 


PARALLEL 
- 
24 programmable 
lines 
using 
one 
8255A 


SERIAL 
- 
1 programmable 
line 
using 
one 8251A 


iSBX 
MULTIMODULE 
- 
2 iSBX 
MULTIMODULE 
boards 


Serial Communications 
Characteristics 


SYNCHRONOUS 
- 
5-8 
bit characters; 
internal 
or 


external 
character 
synchronization; 
automatic 


sync 
insertion 


ASYNCHRONOUS 
- 
5-8 
bit 
characters; 
break 


character 
generation; 
1, 1Vz, or 2 stop 
bits; 
false 


start 
bit detection 


BAUD 
RATES 


Frequency 
(kHz) 
Baud 
Rate (Hz) 
(Software 
Selectable) 
Synchronous 
Asynchronous 


+ 16 
+64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 
1.76 
1760 
110 
- 


NOTES: 
Frequencyselected by I/Owrite of appropriate 16·bitfrequency 
factor to baud rate register (8253Timer 2). 
Timers 


INPUT 
FREQUENCIES 


Reference: 
2.458 MHz 
± 0.1 % (406.9 nsec 
period, 


nominal); 
or 1.229 MHz' ± 0.1% 
(813.8 nsec 
period, 


nominal); 
or 153.6 kHz 
±0.1% 
(6.510p.sec 
period, 


nominal) 


NOTES: 
Above frequencies are user selectable. 


Event 
Rate: 
2.46 MHz max 


OUTPUT 
FREQUENCIESITIMING 
INTERVALS 


Dual 
Single 
Timer/Counter 
Function 
Timer/Counter 
(Two Timers 
Cascaded) 


Min 
Max 
Min 
Max 


Real·time 
1.63~s 
427.1ms 
3.26s 
466.50min 


Interrupt 


Programmable 
1.63~s 
427.1ms 
3.26s 
466.50min 


one·shot 


Rategenerator 2.342Hz 613.5kHz 0.000036Hz 306.8kHz 
Square-wave 
2.342Hz 613.5kHz 0.000036Hz 306.8kHz 


rate generator 


Software 
1.63~s 
427.1ms 
3.26s 
466.50min 


triggered 
strobe 


Hardware 
1.63~s 
427.1ms 
3.26s 
466.50min 


triggered 
strobe 


Event 
- 
2.46 MHz 
- 
- 
counter 


intel" 


Interfaces 


MUL TIBUS 
- 
All signals 
TTL compatible 


iSBX 
BUS - 
All signals 
TTL compatible 


PARALLEL 
I/O - 
All signals 
TTL compatible 


SERIAL 
I/O - 
RS232C 
compatible, 
configurable 
as a data set or data terminal 


TIMER 
- 
All signals 
TTL compatible 


INTERRUPT 
REQUESTS 
- 
All TTL compatible 


Connectors 


Double· 


IntElrface 
'Sided 
Centers 
Mating 
Pins 
(in.) 
Connectors 
(qty) 


MULTIBUS 
86 
0.156 
Viking 
System 
3KH43/9AMK12 
Wire Wrap 


iSBX Bus 


8-Bit Data 
36 
0.1 
iSBX 960-5 


Parallel I/O 
50 
0.1 
3M 3415-000 Flat 


(2) 
or 
TI H312125 Pins 


Serial 110 
26 
0.1 
3M 3462-0001 
Flat 
or 
AMP 88106-1 Flat 


Line Drivers and Terminators 


I/O DRIVERS 
- 
The following 
line 
drivers 
are all 
compatible 
with 
the 110driver 
sockets 
on the iSBC 
88/25 board 


Driver 
Characteristic 
Sink Current 
(mA) 


7438 
I,OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


NOTES: 
I= inverting; NI = non-inverting; OC= open collector. 


Port 1 of the 8255A 
has 32 mA totem-pole 
bidirec- 
tional 
drivers 
and 
10 kO terminators 


110 TERMINATORS 
- 
220013300 
divider 
or 1 kO 
pullup 


2200/3300 (iSBC 901 OPTION) 


22011 


+5V 
; 


____ 
33~ 
1 
.r 
-----L-..o 


--------------------- 
1 kO (iSBC 902 OPTION) 


1 kO 


+5V 
V\~~-------o 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-State 
32 


Address 
Tri-State 
24 


Commands 
Tri-State 
32 


Bus Control 
Open Collector 
20 


Physical Characteristics 


WIDTH 
- 
12.00 in. (30.48 cm) 


HEIGHT 
- 
6.75 in. (17.15 cm) 


DEPTH 
- 
0.70 in. (1.78 cm) 


WEIGHT 
- 
14 oz (388 gm) 


Electrical 
Characteristics 


DC POWER 
REQUIREMENTS 


Current 
Requirements 


Configuration 
(All Voltages 
± 5%) 


+5V 
+12V 
-12V 


Without 
EPROM' 
3.8A 
25 mA 
23mA 


RAM only2 
104 mA 


With 8K EPROM3 
4.3A 
25 mA 
23 mA 


(using 2716) 


With 16K EPROM3 
4.4A 
25 mA 
23 mA 


(using 2732) 


With 32K EPROM3 
4.4A 
25 mA 
23 mA 


(using 2764) 


NOTES: 
1. Does not 
include 
power 
for optional 
ROM/EPROM, I/O 


drivers, and 110 terminators. 
2. RAM chips powered via auxiliary power bus in power-down 
mode. Does not include power for optional RAM. 


3. Includes power required for 4 ROM/EPROM chips, and I/O 


terminators 
installed for 16 110 lines; all terminator 
inputs 


low. 


Environmental 
Characteristics 


OPERATING 
TEMPERATURE 
- 
O°C to 55°C 


RELATIVE 
HUMIDITY 
- 
to 90% 
(without 
conden- 


sation) 


Reference Manual 


143825·001 
- 
iSBC 
88/25 
Hardware 
Reference 


Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel 
sales 
rep- 


resentative, 
distributor 
office 
or from 
Intel 
litera- 


ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 


Clara, 
California 
95051. 


ORDERING INFORMATION 
Part Number 
Description 


SBC 88/25 
8·bit 
Single 
Board 
Computer 


with 
4K bytes 
RAM 


inter 


iSBC™ 86/14 and iSBC™ 86/30 
SINGLE 
BOARD COMPUTERS 


• iAPX 86/10 (8086·2) Microprocessor 


with 5 or 8 MHz CPU clock 


• Fully software 
compatible 
with iSBC™ 


86/12A Single Board Computer 


• Optional 
iAPX 86/20 Numeric 
Data 


Processor 
with iSBC™ 337 


MULTIMODULE™ 
processor 


• 32K1128K bytes of dual·port 
read/write 


memory 
expandable 
on·board 
to 256K 


bytes with on·board 
refresh 


• Sockets 
for up to 64K bytes of J EDEC 


24/28·pin standard 
memory devices 


• Two iSBX™ bus connectors 


• 24 programmable 
parallel 
110lines 


• Programmable 
synchronous/asynchro· 


nous RS232C compatible 
serial inter- 


face with software 
selectable 
baud 


rates 


• Two programmable 
16·bit BCD or binary 


timers/event 
counters 


• 9 Levels of vectored 
interrupt 
control, 


expandable 
to 65 levels 


• MUL TIBUS@interface 
for multi master 


configurations 
and system 
expansion 


• Supported 
by a complete 
family 
of 


single 
board computers, 
memory, 


digital 
and analog 110,peripheral 


controllers, 
packaging 
and software 


The iSBC 86/14 and iSBC 86/30 Single 
Board Computers 
are members 
of Intel's 
complete 
line of OEM 


microcomputer 
systems 
which 
take full 
advantage 
of Intel's 
technology 
to provide 
economical, 
self- 


contained, 
computer-based 
solutions 
for OEM applications. 
Each board is a complete 
computer 
system 
on a single 6.75 x 12.00·in. printed 
circuit 
card distinguished 
by RAM memory content 
with 32K bytes and 


128K bytes 
provided 
on the iSBC 86/14 and iSBC 86/30 
board, 
respectively. 
The CPU, system 
clock, 


readlwrite 
memory, 
nonvolatile 
read only memory, 
110 ports and drivers, serial communications 
interface, 


priority 
interrupt 
logic and programmable 
timers, 
all reside on the boards. 


The fOllowing 
are trademarks 
of Intel 
Corporation 
and 
may be used 
only 
10 describe 
Intet 
prOducts: 
CREDIT, 
Index, 
Intel, 
Insite, 
Inlellee, 
library Manager, 
Megachassis, 


Micromap, 
MULTIBUS, 
PROMPT, 
UPI, I'Scope, 
Promware, 
MeS, 
ICE, iAMX, 
iSBC, 
iSBX, MULTIMODULE 
and iCS.lntel 
Corporation 
assumes 
no responsibility 
for the use of any 


circuitry 
other 
than circuitry 
embOdied 
in an Intel product. 
No other 
circuil 
patent 
licenses 
are implied. 


Central Processing Unit 


The central 
processor 
for the iSBC 86/XX(1)boards 


is Intel's 
iAPX 86/10 (8086-2) CPU. A clock 
rate of 8 


MHz is supported 
with a jumper 
selectable 
option 
of 5 MHz. 
The CPU architecture 
includes 
four 


16-bit byte addressable 
data registers, 
two 16-bit 


memory 
base pointer 
registers 
and two 16-bit in- 
dex registers, 
all accessed 
by a total of 24 operand 


addressing 
modes for comprehensive 
memory ad- 
dressing 
and for support 
of the data 
structures 


required 
for 
today's 
structured, 
high 
level 
lan- 
guages as well as assembly 
language. 


Instruction Set 


The 8086 instruction 
repertoire 
includes 
variable 
length 
instruction 
format 
(including 
double 
oper- 
and instructions), 
8-bit and 16-bit signed 
and un- 
signed 
arithmetic 
operators 
for binary, 
BCD and 


unpacked 
ASCII data, and iterative 
word and byte 


string 
manipulation 
functions. 


For enhanced 
numerics 
processing 
capability, 
the 
iSBC 337 MULTIMODULE 
Numeric 
Data Processor 
extends 
the iAPX 86/10 architecture 
and data set. 


Over 
60 numeric 
instructions 
offer 
arithmetic, 


trigonometric, 
transcendental, 
logarithmic 
and ex- 


ponential 
instructions. 
Supported 
data 
types 
in- 


clude 
16, 32, and 64·bit integer, 
and 32 and 64-bit 
floating 
point, 18-digit packed BCD and 80-bit tem- 
porary. 


Architectural 
Features 


A 6-byte 
instruction 
queue 
provides 
pre-fetching 
of sequential 
instructions 
and can reduce the 750 
nsec minimum 
instruction 
cycle 
to 250 nsec for 
queued 
instructions. 
The stack-oriented 
architec- 
ture 
readily 
supports 
modular 
programming 
by 
facilitating 
fast, simple, 
inter-module 
communica- 


tion, 
and other 
programming 
constructs 
needed 
for asynchronous 
real-time 
systems. 
The memory 
expansion 
capabilities 
offer 
a 1 megabyte 
ad- 


dressing 
range. The dynamic 
relocation 
scheme 
allows 
ease 
in segmentation 
of pure 
procedure 
and data for efficient 
memory utilization. 
Four seg- 


ment 
registers 
(code, 
stack, 
data, 
extra) 
contain 
program 
loaded 
offset 
values 
which 
are used to 
map 
16-bit addresses 
to 20-bit 
addresses. 
Each 
register 
maps 64K bytes at a time and activation 
of 
a specific 
register 
is controlled 
explicitly 
by pro- 


gram 
control 
and 
is also 
selected 
implicitly 
by 
specific 
functions 
and instructions. 


RAM Capabilities 


The iSBC 86/14 and iSBC 86/30 microcomputers 
contain 
32K bytes 
and 
128K bytes 
of dual-port 
dynamic 
RAM, respectively. 
In addition, 
on-board 


inter 


RAM may be doubled on each microcomputer by 
optionally 
adding RAM MULTIMODULE boards. 


The on-board RAM may be expanded to 256Kbytes 
with the iSBC 304 MULTIMODULEBoard mounted 
onto the iSBC 89/30 board. Likewise, the iSBC 
86/14 microcomputer 
may be expanded to 64K 


bytes with the iSBC 300A MULTIMODULEoption. 
The dual-port controller allows access to the on- 
board RAM (including RAM MULTIMODULE op- 
tions) from the iSBC 86/XX boards and from any 
other 
MULTIBUS master via the system 
bus. 
Segments of on-board RAM may be configured as 
a private resource, protected 
from MULTIBUS 


system access. The amount of memory allocated 
as a private resource may be configured in in· 
crements of 25% of the total on-board memory 
ranging 
from 
0% 
to 
100% 
(optional 
RAM 


MULTIMODULE boards double 
the increment 


size). These features allow the multiprocessor 
systems to establish local memory for each pro- 
cessor and shared system memory configurations 
where the total system memory size (including 
local on·board memory) can exceed one megabyte 
without addressing conflicts. 


EPROM Capabilities 


Four 28-pin sockets are provided for the use of Intel 
2716s,2732As,2764s,27128s,and their respective 
ROMs. When using 27128s, the on-board EPROM 
capacity is 64K bytes. Other JEDEC standard 
pinout devices are also supported, including byte- 
wide static RAMs. 


Parallel I/O Interface. 


The iSBC 86/XX Single Board Computers contain 
24 programmable parallel I/O lines implemented 
using the Intel 8255A Programmable Peripheral 
Interface. The system software is used to config- 
ure the I/O lines in any combination of unidirec- 


tional input/output 
and bidirectional 
ports indi- 


cated in Table 1. In order to take advantage of the 
large number of possible I/O configurations, sock- 
ets are provided 
for interchangeable 
I/O line 


drivers and terminators, allowing the selection of 
the appropriate 
combination 
of optional 
line 


drivers and terminators with the required drive/ter- 
mination characteristics. 
The 24 programmable 


I/O lines and signal ground lines are brought out to 
a 50-pin edge connector. 


A programmable communications interface using 
the Intel 8251A Universal Synchronous/Asynchro· 
nous Receiver/Transmitter (USART) is contained 
on the iSBC 86/XX boards. A software selectable 
baud rate generator provides the USART with all 
common communication frequencies. The mode 
of operation (i.e., synchronous or asynchronous), 
data format, control character format, parity, and 
baud rate are all under program control. The 8251A 
provides full duplex, double buffered transmit and 
receive capability. 
Parity, overrun, and framing 


error detection are all incorporated in the USART. 
The RS232Ccommand lines, serial data lines and 
signal ground line are brought out to a 26-pin edge 
connector. 


Programmable Timers 


The iSBC 86/XXboards provide three independent, 
fully programmable 16·bit interval timers/event 
counters utilizing the Intel 8253 Programmable 
Interval Timer. Each counter is capable of oper- 
ating in either BCD or binary modes. Two of these 
timers/counters are available to the systems de- 
signer to generate accurate time intervals under 
software control. 
Routing for the outputs 
and 


gate/trigger inputs of two of these counters is 
jumper selectable. The outputs may be indepen- 


Mode of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Latched 
Latched & 
Latched 
Latched & 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X' 


4 
X 
X 
x1 


NOTE: 
1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed i·nput or a latched and 
strobed output port or port 1 is used as a bidirectional 
port. 


denlly 
routed 
to the 8259A Programmable 
Inter- 
rupt Controller 
and to the 1/0 terminators 
associ- 
ated with the 8255A to allow external devices or an 
8255A port to gate the timer 
or to count 
external 
events. 
The third 
interval 
timer 
in the 8253 pro- 
vides 
the programmable 
baud rate generator 
for 
the iSBC 86/XX 
boards' 
RS232C USART serial port. 


The system 
software 
configures 
each timer 
inde· 
pendently 
to select 
the desired 
function. 
Seven 
functions 
are available 
as shown 
in Table 2. The 
contents 
of each counter 
may be read at any time 
during 
system 
operation. 


Table 2. 
Programmable 
Timer 
Functions 


Function 
Operation 


Interrupt on 
When terminal count is reached, an 


terminal count 
interrupt request is generated. This 
function 
is extremely 
useful 
for 
generation of real-time clocks. 


Programmable 
Output goes low upon receipt of an 


one-shot 
external trigger edge or software 
command and returns high when 
terminal 
count 
is reached. This 
function is retriggerable. 


Rate 
Divide by N counter. The output will 


generator 
go low for one input clock cycle, 
and the period from one low going 
pulse to the next is N times the in- 
put clock period. 


Square-wave 
Output will remain high until one· 
rate generator 
half the count has been completed, 
and go low for the other half of the 
count. 


Software 
Output remains high until software 
triggered 
loads count 
(N). N counts 
after 


strobe 
count is loaded, output goes low for 
one input clock period. 


Hardware 
Output 
goes low for one clock 
triggered 
period N counts after rising edge 
strobe 
counter trigger input. The counter 
is retriggerable. 


Event counter 
On a jumper selectable basis, the 
clock input becomes an input from 
the external system. CPU may read 
the number of events occurring 
after the counter 
"wiodow" 
has 
been enabled or an interrupt may be 
generated after N events occur in 
the system. 


iSBX™ MULTIMODULE'M On·Board 
Expansion 


Two 8/16·bit iSBX MULTIMODULE 
connectors 
are 
provided 
on 
the 
iSBC 
86/XX 
microcomputers. 
Through 
these connectors, 
additional 
on-board 
110 
functions 
may 
be added. 
iSBX 
MUL T1MODULE 


boards 
optimally 
support 
functions 
provided 
by 
VLSI 
peripheral 
components 
such 
as additional 
parallel 
and 
serial 
1/0, 
analog 
1/0, 
small 
mass 
storage 
device 
controllers 
(e.g., 
cassettes 
and 
floppy disks), and other custom 
interfaces 
to meet 
specific 
needs. By mounting 
directly 
on the single 
board computer, 
less interface 
logic, 
less power, 


simpler 
packaging, 
higher performance, 
and lower 
cost 
result 
when 
compared 
to other 
alternatives 
such as MULTIBUS form factor compatible 
boards. 


The iSBX connectors 
on the iSBC 
86/XX 
boards 
provide 
all signals 
necessary 
to interface 
to the 
local on·board bus, including 
16 data lines for max- 
imum 
data 
transfer 
rates. 
iSBX 
MULTIMODULE 
boards 
designed 
with 
8-bit data paths and using 
the 8·bit iSBX connector 
are also supported 
on the 
iSBC 
86/XX 
microcomputers. 
A broad 
range 
of 


iSBX MULTIMODULE 
options 
are available 
in this 
family 
from Intel. Custom 
iSBX modules 
may also 
be designed 
for use on the iSBC 86/XX 
boards. An 


iSBX bus interface 
specification 
and iSBX connec- 
tors are available 
from Intel. 


MULTIBUS@SYSTEM 
BUS AND 
MULTIMASTER CAPABILITIES 


Overview 


The 
MUL TIBUS 
system 
bus 
is 
Intel's 
industry 
standard 
microcomputer 
bus structure. 
Both 8 and 
16-bit single 
board 
computers 
are supported 
on 
the MULTIBUS 
structure 
with 
24 address 
and 16 


data 
lines. 
In 
its 
simplest 
application, 
the 


MULTIBUS system 
bus allows 
expansion 
of func· 


tions 
already 
contained 
on a single 
board 
com· 


puter (e.g., memory 
and digital 
1/0). However, 
the 


MULTIBUS 
structure 
also 
allows 
very 
powerful 


distributed 
processing 
configurations 
with 
multi- 
ple 
processors 
and 
intelligent 
slave 
1/0, 
and 
peripheral 
boards 
capable 
of 
solving 
the 
most 


demand ing microcomputer 
appl ications. 
The 


MULTIBUS 
system 
bus is supported 
with a broad 
array of board level products, 
LSI interface 
com· 


ponents, detailed 
published 
specifications 
and ap· 


plication 
notes. 


Expansion Capabilities 


Memory and 1/0 capacity 
may be expanded 
and ad· 
ditional 
functions 
added 
using 
Intel 
MULTIBUS 


compatible 
expansion 
boards. Memory may be ex- 


panded by adding 
user specified 
combinations 
of 


RAM 
boards, 
EPROM 
boards, 
or 
combination 


boards. 
Inputloutput 
capacity 
may be added with 
digital 
1/0 and analog 
1/0 expansion 
boards. 
Mass 


storage 
capability 
may 
be achieved 
by adding 


single 
or double 
density 
diskette 
controllers, 
or 


hard disk 
controllers. 
Modular 
expandable 
back- 
planes 
and 
cardcages 
are available 
to 
support 
multiboard 
systems. 


Multimaster 
Capabilities 


For those 
applications 
requiring 
additional 
pro- 
cessing 
capacity 
and 
the 
benefits 
of 
multi- 
processing 
(I.e., several 
CPUs and/or 
controllers 
logically 
sharing 
system 
tasks through 
communi- 
cation 
of the system 
bus), the iSBC 86/XX boards 
provide 
full 
MUL T1BUS arbitration 
control 
logic. 
This control 
logic 
allows 
up to three iSBC 86/XX 
boards 
or other 
bus masters, 
including 
iSBC 80 
family 
MULTIBUS 
compatible 
8-bit 
single 
board 
computers 
to share the system 
bus using a serial 
(daisy chain) priority 
scheme 
and allows 
up to 16 
masters 
to share the MULTIBUS 
system 
bus with 
an external 
parallel 
priority 
decoder. 
In addition 
to 
the multiprocessing 
configurations 
made 
possi- 
ble with multi master capability, 
it also provides 
a 
very 
efficient 
mechanism 
for all 
forms 
of 
DMA 
(Direct 
Memory Access) 
transfers. 


Interrupt Capability 


The iSBC 86/XX boards 
provide 
9 vectored 
inter- 
rupt 
levels. 
The 
highest 
level 
is the 
NMI 
(Non- 
Maskable 
Interrupt) 
line which 
is directly 
tied to 
the 8086 CPU. This interrupt 
is typically 
used for 
signaling 
catastrophic 
events (e.g., power failure). 
The Intel 8259A Programmable 
Interrupt 
Controller 
(PIC) provides 
control 
and vectoring 
for the next 
eight interrupt 
levels. As shown in Table 3, a selec- 
tion of four priority 
processing 
modes is available 
for use in designing 
request processing 
configura- 
tions 
to match 
system 
requirements 
for efficient 
interrupt 
servicing 
with 
minimal 
latencies. 


Operating 
mode and priority 
assignments 
may be 


reconfigured 
dynamically 
via software 
at any time 


Table 3. Programmable 
Interrupt 
Modes 


Mode 
Operation 


Fully nested 
Interrupt request line priorities fixed 
at 0 as highest, 7 as lowest. 


Auto·rotating 
Equal priority. Each level, after re- 
ceiving service, becomes the lowest 
priority level until next interrupt oc· 
curs. 


Specific 
System 
software 
assigns 
lowest 
priority 
priority 
level. Priority 
of all other 
levels based in sequence numeric- 
ally on this assignment. 


Polled 
System software examines priority- 
encoded system interrupt status via 
interrupt status register. 


during 
system 
operation. 
The PIC accepts 
inter- 


rupt requests 
from all on-board 
I/O resources 
and 


from 
the 
MULTIBUS 
system 
bus. The 
PIC then 


resolves 
requests 
according 
to the selected 
mode 


and, if appropriate, 
issues an interrupt 
to the CPU. 


Any combination 
of interrupt 
levels may be masked 


via software, 
by storing 
a single 
byte in the inter- 


rupt mask register of the PIC. In systems 
requiring 


additional 
interrupt 
levels, slave 8259A PICs may 


be interfaced 
via the MULTIBUS 
system 
bus, to 


generate 
additional 
vector 
addresses, 
yielding 
a 


total of 65 unique 
interrupt 
levels. 


Interrupt Request Generation 


Interrupt 
requests 
to 
be serviced 
by the 
iSBC 


86/XX boards may originate 
from 28 sources. Table 


4 includes 
a list 
of devices 
and 
functions 
sup- 


ported 
by 
interrupts. 
All 
interrupt 
signals 
are 


brought 
to the interrupt 
jumper 
matrix 
where any 


combination 
of interrupt 
sources 
may be strapped 


to the desired 
interrupt 
request level on the 8259A 


PIC or the NMI input to the CPU directly. 


Power· Fail Control and Auxiliary Power 


Control 
logic 
is also included 
to accept 
a power- 


fail interrupt 
in conjunction 
with the AC-Iow signal 


from the iSBG 635 and iSBC 640 Power Supply or 
equivalent, 
to initiate 
an orderly 
shut down of the 


system 
in the event of a power failure. 
Addition- 


ally, an active-low 
TIL compatible 
memory protect 


signal 
is brought 
out on the auxiliary 
connector 


which, 
when asserted, 
disables 
read/write 
access 


to RAM memory 
on the board. This 
input 
is pro- 


vided for the protection 
of RAM contents 
during 


system 
power-down 
sequences. 
An 
auxiliary 


power 
bus 
is 
also 
provided 
to 
allow 
separate 


power to RAM for systems 
requiring 
battery 
back- 


up of read/write 
memory. 
Selection 
of this 
auxil- 


iary RAM power 
bus is made via jumpers 
on the 


board. 


System Development Capabilities 


The development 
cycle 
of 
iSBC 86/XX products 


can 
be significantly 
reduced 
and 
simplified 
by 


using 
either 
the 
System 
86/330 
or 
the 
Intellec 


Series Microcomputer 
Development 
Systems. The 


Assembler, 
Locating 
Linker, Library Manager, Text 


Editor and System Monitor are all supported 
by the 


ISIS-II disk-based 
operating 
system. 
To facilit~te 


conversion 
of 8080A/8085A 
assembly 
language 


programs 
to 
run 
on 
the 
iSBC 
86/XX 
boards, 


CONV·86 
is available 
under 
the ISIS-II operating 


system. 


IN-CIRCUIT 
EMULATOR 


The 
Intellec 
ICE-86 
In-Circuit 
Emulator 
provides 


the necessary 
link 
between 
the software 
develop- 
ment environment 
provided 
by the Intellec 
system 


and the "target" 
iSBC 86/XX 
execution 
system. 
In 


addition 
to providing 
the 
mechanism 
for 
loading 


executable 
code 
and 
data 
into 
the 
iSBC 
86/XX 


boards, 
the 
ICE-86 In-Circuit 
Emulator 
provides 
a 


sophisticated 
command 
set to assist 
in debugging 


software 
and final 
integration 
of the user hardware 
and software. 


PUM·86 


Intel's 
system's 
implementation 
language, 
PUM-86, 
is 
standard 
in 
the 
System 
86/330 
and 
is 
also 


available 
as an Intellec 
Microcomputer 
Develop- 


ment 
System 
option. 
PUM-86 
provides 
the 
capa- 


bility 
to program 
in algorithmic 
language 
and elim- 


inates the need to manage 
register 
usage or allocate 


memory 
while 
still 
allowing 
explicit 
control 
of the 


system's 
resources 
when 
needed. 
FORTRAN 
86 


and 
PASCAL 
86 are also 
available 
on 
Intellec 
or 
86/330 
systems. 


Run-Time Support 


Intel 
also 
offers 
two 
run-time 
support 
packages; 


iRMX 88 Realtime 
Multitasking 
Executive 
and the 
i RMX 86 Operating 
System. 
The i RMX 88 executive 


is a simple, 
highly 
configurable 
and efficient 
foun- 


dation 
for 
small, 
high 
performance 
applications. 


Its mUltitasking 
structure 
establishes 
a solid 
foun- 


dation 
for 
modular 
system 
design 
and 
provides 


task 
scheduling 
and management, 
intertask 
com- 


munication 
and 
synchronization, 
and 
interrupt 


servicing 
for a variety 
of peripheral 
devices. 
Other 
configurable 
options 
include 
terminal 
handlers, 


disk file system, 
debuggers 
and other 
utilities. 
The 


iRMX 
86 Operating 
System 
is a high 
functional 


operating 
system 
with 
a very 
rich 
set of features 


and options 
based 
on an object-oriented 
architec- 


ture. 
In 
addition 
to 
being 
modular 
and 
con- 


figurable, 
functions 
beyond 
the. nucleus 
include 
a 


sophisticated 
file 
management 
and 
1/0 
system, 


and powerful 
human 
interface. 
Both 
packages 
are 


easily 
customized 
and 
extended 
by the 
user 
to 


match 
unique 
requirements. 


Device 
Function 
Number 
of 


Interrupts 


MULTlBUS~ interface 
Requests 
from 
MULTIBUS~ resident 
peripherals 
or 
8; may be expanded to 


other CPU boards 
64 with slave 8259A 
PICs on MULTIBUS~ 
boards 


8255A Programmable 
Signals input buffer full or output 
buffer empty; also 
3 
Peripheral Interface 
BUS INTR OUT general purpose interrupt 
from driver/ 


terminator 
sockets 


8251A USART 
Transmit buffer empty and receive buffer full 
2 


8253 Timers 
Timer 0, 1 outputs; function 
determined by timer mode 
2 


iSBXTMconnectors 
Function determined 
by iSBXTMMULTIMODULETM 
4 


board 
(2 per iSBXTMconnector) 


Bus fail safe timer 
Indicates 
addressed 
MULTIBUS~ resident 
device has 
1 


not responded to command within 6 msec 


Power fail interrupt 
Indicates AC power is not within tolerance 
1 


Power line clock 
Source of 120 Hz signal from power supply 
1 


External interrupt 
General purpose interrupt 
from auxiliary 
(P2) connec- 
1 


tor on backplane 


iSBCTM337 MULTIMODULETM 
Indicates error or exception 
condition 
1 
Numeric Data Processor 


Parity error 
Indicates on-board RAM parity error from iSBCTM303 
1 


parity MULTIMODULETM board (iSBCTM86/14 option) 


Edge-level conversion 
Converts edge triggered 
interrupt 
request to level in- 


terrupt 
1 


OR-gate matrix 
Outputs of OR-gates on-board for multiple 
interrupts 
2 


inter 


Word Size 


INSTRUCTION 
- 
8, 16, 24, or 32 bits 


DATA 
- 
8, 16 bits 


System Clock 


5.00 MHz or 8.00 MHz 
± 0.1 % (jumper 
selectable) 


Cycle Time 


BASIC 
INSTRUCTION 
CYCLE 


8 MHz - 
750 ns 
- 
250 ns (assumes 
instruction 
in the queue) 


5 MHz- 
1.2/tsec 


- 
400 ns (assumes 
instruction 
in the queue) 


NOTE: Basic instruction 
cycle is defined as the fastest 


instruction time (i.e.,two clock cycles). 


Memory Cycle Time 


RAM - 
750 ns 


EPROM 
- 
Jumper 
selectable 
from 500 ns to 875 ns 


Memory Capacity/Addressing 


ON· BOARD 
EPROM 


Device 
Total Capacity 
Address 
Range 


2716 
8K bytes 
FEOOO-FFFFFH 


2732A 
16K bytes 
FCOOO-FFFFFH 


2764 
32K bytes 
F8000-FFFFFH 


27128 
64K bytes 
FOOOO-FFFFFH 


NOTE: iSBC 86/XXEPROMsockets support JEDEC24/28·pin 


standard EPROMsand RAMs. 


ON· BOARD 
RAM 
Board 
Total 
Capacity 
Address 
Range 


iSBC 86/14 
32K bytes 
0-07FFFH 


iSBC 86/30 
128K bytes 
0-1FFFFH 


WITH 
MULTIMODULE™ 
RAM 
Board 
Total 
Capacity 
Address 
Range 


iSBC 300A 
64K bytes 
O-OFFFFH 


(with 
iSBC 86/14) 
iSBC 304 
256K bytes 
0-3FFFFH 


(with 
iSBC 86/30) 


I/O Capacity 


PARALLEL 
- 
24 programmable 
lines 
using 
one 


8255A. 


SERIAL 
- 
1 programmable 
line 
using 
one 8251A 


iSBX™ 
MUL TIMODULE™ 
- 
2 iSBX boards 


Serial Communications 
Characteristics 


SYNCHRONOUS 
- 
5-8 bit characters; 
internal 
or 


external 
character 
synchronization; 
automatic 


sync 
insertion 


ASYNCHRONOUS 
- 
5-8 
bit 
characters; 
break 


character 
generation; 
1, 1V2, or 2 stop 
bits; 
false 


start 
bit detection 


BAUD 
RATES 


Frequency 
(kHz) 
Baud 
Rate (Hz) 


(Software 
Selectable) 
Synchronous 
Asynchronous 


+16 
+64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


NOTE: Frequency selected by I/O write of appropriate 16·bit 


frequency factor to baud rate register (8253Timer 2). 


Timers 


INPUT 
FREQUENCIES 


Reference: 
2.46 MHz 
± 0.1 % (0.041 /tsec 
period, 


nominal); 
or 153.60 kHz ± 0.1 % (6.51 /tsec 
period, 


nominal) 


NOTE: Above frequencies are user selectable. 


Event 
Rate: 
2.46 MHz max 


OUTPUT 
FREQUENCIES/TIMING 
INTERVALS 


Dual 


Single 
Timer/Counter 


Function 
Timer/Counter 
(Cascaded) 


Min 
Max 
Min 
Max 


Real·time 
1.63~s 
427.1ms 
3.26s 
466.50min 


Interrupt 
Programmable 
1.63~s 
427.1ms 
3.26s 
466.50min 


one·shot 
Rategenerator 2.342Hz 613.5kHz 0.000036Hz 306.8kHz 
Square·wave 
2.342Hz 613.5kHz 0.000036Hz 306.8kHz 


rate generator 
Software 
1.63~s 
427.1ms 
3.26s 
466.50min 


triggered 
strobe 
Hardware 
1.63~s 
427.1ms 
3.26s 
466.50min 
triggered 
strobe 
Event 
- 
2.46MHz 
- 
- 
counter 


Interfaces 


MULTIBUS@ - 
All signals 
TTL compatible 


iSBX™ 
BUS - 
All signals 
TTL compatible 


PARALLEL 
110 - 
All signals 
TTL compatible 


SERIAL 
110 
- 
RS232C 
compatible, 
configurable 


as a data set or data terminal 


inter 


TIMER 
- 
All signals 
TTL compatible 


INTERRUPT 
REQUESTS 
- 
All TIL 
compatible 


Connectors 


Double· 
Centers 
Mating 
Interface 
Sided 
Pins 
(in.) 
Connectors 


MULTIBU~ 
86 
0.156 
Viking 


System 
3KH43/9AMK12 
Wire Wrap 


iSBXTM Bus 
8·Bit Data 
36 
0.1 
iSBX 960·5 


Parallel 110 
50 
0.1 
3M 3415·000 Flat 
(2) 
or 


TI H312125 Pins 


Serial I/O 
26 
0.1 
3M 3462·0001 
Flat or 
AMP 88106·1 Flat 


Line Drivers and Terminators 


I/O DRIVERS 
- 
The following 
line 
drivers 
are all 


compatible 
with 
the I/O driver 
sockets 
on the iSBC 


86/05 board 


Driver 
Characteristic 
Sink Current 
(mA) 


7438 
I,OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


NOTE: I = inverting; NI = non·inverting; OC= open collector. 


Port 1 of the 8255A 
has 20 mA totem-pole 
bidirec- 
tional 
drivers 
and 1 kO terminators 


I/O TERMINATORS 
- 
2200/3300 
divider 
or 1 kO 
pullup 


2200/3300 
(ISBCTM 901 OPTION) 


220ll 
+5~~_;~:_1---0 


1 kO (iSBC™ 
902 OPTION) 
1 to 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-State 
32 


Address 
Tri·State 
32 


Commands 
Tri·State 
32 


Bus Control 
Open Collector 
20 


Physical 
Characteristics 


WIDTH 
- 
12.00 in. (30.48 cm) 


HEIGHT 
- 
6.75 in. (17.15 cm) 


DEPTH':'" 
0.70 in. (1.78 cm) 


WEiGHT 
- 
14 oz (388 gm) 


Environmental 
Characteristics 


OPERATING 
TEMPERATURE 
- 
O°C to 55°C 


RELATIVE 
HUMIDITY 
- 
to 90% 
(without 
conden- 


sation) 


Electrical 
Characteristics 


DC POWER 
REQUIREMENTS 


Current 
Requirements 


Configuration 
(All Voltages 
:t 5%) 


+5V 
+12V 
-12V 


Without 
EPROM' 
5.1A 
25 mA 
23 mA 


RAM only2 
600 mA 
- 
- 


With 8K EPROM3 
5.4A 
25 mA 
23 mA 


(using 2716) 


With 16K EPROM3 
5.5A 
25 mA 
23 mA 


(using 2732A) 


With 32K EPROM3 
5.6A 
25 mA 
23mA 


(using 2764) 


NOTES: 
1. Does not 
include 
power for 
optional 
ROM/EPROM, I/O 


drivers, and I/O terminators. 
2. RAM chips powered via auxiliary power bus in power·down 


mode. 


3. Includes power required for 4 ROM/EPROM chips, and I/O 
terminators 
installed for 16 I/O lines; all terminator 
inputs 


low. 


Environmental 
Characteristics 


OPERATING 
TEMPERATURE 
- 
O°C to 55°C 


RELATIVE 
HUMIDITY 
- 
to 90% 
(without 
conden- 


sation) 


Reference 
Manual 


144044·001 
- 
iSBC 
86/14 
and 
iSBC 
86/30 
Hard- 


ware 
Reference 
Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel 
sales 
rep- 


resentative, 
distributor 
office 
or from 
Intel 
litera- 


ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 


Clara, 
California 
95051. 


Part Number 


SBC 86/14 


SBC 86/30 


Description 


Single 
Board 
Computer 


Single 
Board 
Computer 
, 


iSBC™ 86/12A or (pSBC 86/12A*) 


SINGLE 
BOARD COMPUTER 


.8086 
16·bit HMOS microprocessor 


central 
processor 
unit 


• 32K bytes of dual·port 
read/write 


memory 
expandable 
on· board to 64K 


bytes with on· board refresh 


• Sockets 
for up to 16K bytes of read only 


memory 
expandable 
on·board 
to 32K 


bytes 


• System memory 
expandable 
to 1 mega· 


byte 


• 24 programmable 
parallel 
I/O lines with 


sockets 
for interchangeable 
line drivers 


and terminators 


• Programmable 
synchronous/asynchro· 


nous RS232C compatible 
serial 


interface 
with software 
selectable 


baud rates 


• Two programmable 
16·bit BCD or binary 


timers/event 
counters 


• 9 levels of vectored 
interrupt 
control, 


expandable 
to 65 levels 


• Auxiliary 
power bus and power fail 


interrupt 
control 
logic for read/write 


memory 
battery 
backup 


• MULTIBUS® interface 
for multimaster 


configurations 
and system 
expansion 


• Compatible 
with iSBC 337 MULTI· 


MODULE™ Numeric 
Data Processor 


• Compatible 
with iSBC 80 family 
single 


board computers, 
memory, 
digital 
and 


analog 
I/O, and peripheral 
controller 


boards 


The iSBC 86/12A Single Board Computer 
is a member of Intel's complete 
line of OEM microcomputer 
systems which take 


full 
advantage 
of 
Intel's 
LSI technology 
to provide 
economical 
self-contained 
computer 
based 
solutions 
for 
OEM 


applications. 
The 
iSBC 
86/12A 
board 
is a complete 
computer 
system 
on a single 
6.75 x 12.00-inch 
printed 
circuit 


card. 
The 
CPU, 
system 
clock, 
read/write 
memory, 
nonvolatile 
read 
only 
memory, 
I/O 
ports 
and 
drivers, 
serial 
communications 
interface, 
priority 
interrupt 
logic 
and programmable 
timers, 
all reside on the board. 
Full MUL TIBUS 


interface 
logic 
is included 
to offer 
compatibility 
with 
the Intel 
OEM Microcomputer 
Systems 
family 
of Single 
Board 


Computers, 
expansion 
memory 
options, 
digital 
and analog 
I/O expansion 
boards 
and peripheral 
controllers. 


The following 
are trademarks 
of Intel 
Corporation 
and may be used only 
to describe 
Intel products: 
Index, 
Intel, 
Insite, 
Jolellec, 
Library 
Manager, 
Megachassis, 
Micromap. 


MULTIBUS, 
PROMPT, 
IAMX, 
UPI, ,uScope, 
Promware, 
MeS, 
ICE, iSBC, 
iSBX, 
MUlTIMODULE 
and iCS.lnlet 
Corporation 
assumes 
no responsibility 
for the use of any circuitry 


other 
than circuitry 
embodied 
in an Intel product. 
No other circuit 
patent 
licenses 
are implied 


© INTEL CORPORATION, 
1980. 1981 
September 
1981 


3-81 
9803115A.Ol 


Central Processing Unit 


The central 
processor 
for the iSBC 86/12A board is Intel's 


8086, a powerful 
16-bit 
HMOS 
device. 
The 
225 sq. mil 


chip 
contains 
29,000 transistors 
and has a clock 
rate of 


5MHz. 
The 
architecture 
includes 
four 
(4) 
16-bit 
byte 


addressable 
data registers, 
two 
(2) 16-bit 
memory 
base 


pointer 
registers 
and two 
(2) 16-bit 
index 
registers, 
all 


accessed 
by a total of 24 operand 
addressing 
modes for 
complex 
data 
handling 
and 
very 
flexible 
memory 
addressing. 


Instruction 
Set - 
The 8086 instruction 
repertoire 
includes 


variable 
length 
instruction 
format 
(including 
double 


operand 
instructions), 
8-bit 
and 
16-bit 
signed 
and 


unsigned 
arithmetic 
operators 
for 
binary, 
BCD 
and 


unpacked 
ASCII data, and iterative 
word and byte string 
manipulation 
functions. 
In addition, 
the iSBC 337 MUL- 


TIMODULE 
Numeric 
Data Processor 
may be installed 
to 
add over 60 numeric 
instructions 
and hardware 
support 
for 
mUltiple 
precision 
integer 
and 
floating 
point 
data 


types. 


Architectural 
Features 
- 
A 6-byte 
instruction 
queue 
provides 
pre-fetching 
of sequential 
instructions 
and can 


reduce the 1.2l'sec 
minimum 
instruction 
cycle to 400 nsec 


for queued 
instructions. 
The stack oriented 
architecture 
facilitates 
nested subroutines 
and co-routines, 
reentrant 


code 
and 
powerful 
interrupt 
handling. 
The 
memory 


expansion 
capabilities 
offer 
a 1 megabyte 
addressing 


range. 
The 
dynamic 
relocation 
scheme 
allows 
ease 
in 


segmentation 
of 
pure 
procedure 
and 
data 
for 
efficient 


memory 
utilization. 
Four segment 
registers 
(code, stack, 


data, extra) 
contain 
program 
loaded 
offset 
values which 


are used 
to map 
16-bit 
addresses 
to 20-bit 
addresses. 


Each register 
maps 64K-bytes 
at a time and activation 
of a 


specific 
register 
is controlled 
explicitly 
by 
program 


control 
and is also selected implicitly 
by specific 
functions 


and instructions. 


Bus Structure 


The 
iSBC 
86/12A 
microcomputer 
has three 
buses: 
an 
internal 
bus for communicating 
with 
on-board 
memory 


and I/O options, 
the MUL TIBUS system bus for referenc- 


ing additional 
memory 
and I/O options, 
and the dual-port 


bus which 
allows 
access to RAM from the on-board 
CPU 


and 
the 
MUL TIBUS 
system 
bus. 
Local 
(on-board) 


accesses 
do 
not 
require 
MUL T1BUS 
communication, 


making 
the 
system 
bus 
available 
for 
use 
by 
other 
MUL TIBUS 
masters 
(i.e. DMA devices 
and other 
single 


board 
computers 
transferring 
to additional 
system 


memory). 
This feature allows true parallel 
processing 
in a 
multiprocessor 
environment. 
In addition, 
the MUL TIBUS 
interface 
can be used for system 
expansion 
through 
the 


use of other 
8- and 16-bit 
iSBC computers, 
memory 
and 


I/O expansion 
bOards. 


RAM Capabilities 


The iSBG 86/12A microcomputer contains 32K bytes of 
dynamic read/write memory using 16K-bit 2117 RAMs. In 
addition, the on-board RAM complement may be ex- 
panded to 64K bytes with the iSBG 300 32K-byte MULTI- 
MODULE RAM option. Power for the on-board RAM and 
refresh circuitry may be optionally provided on an aux- 
Iliary power bus, and memory protect logic is included 
for RAM battery backup requirements. The iSBG 86/12A 
board contains a dual-port controller which allows ac- 
cess to the on-board RAM (32K bytes or 64K bytes when 
the iSBG 300 module is included with the iSBG 86/12A 
board) from the iSBG 86/12A GPU and from any other 
MULTIBUS master via the system bus. The dual-port 
controller 
allows 
8- and 16-bit accesses 
from 
the 
MULTIBUS system bus, and the on-board GPUtransfers 
data to RAM over a 16-bit data path. Priorities have been 
established such that memory refresh is guaranteed by 
the on-board refresh logic and that the on-board GPU 
has priority over MULTIBUSsystem bus requests forac- 
cess to RAM. The dual-port controller 
includes inde- 


pendent addressing logic for RAM access from the on- 
board GPUand from the MULTIBUSsystem bus. The on- 
board GPUwill always access RAM starting at location 
OOOOOH' Address jumpers allow on-board RAM to be 
located starting on any 8K-byte boundary within 
a 1 
megabyte address range for accesses from the MULTI- 
BUS system bus. In conjunction 
with this feature, the 
iSBG 86/12A microcomputer 
has the ability to protect 
on-board memory from MULTIBUS access to any con- 
tiguous 8K-byte segments (or 16K-byte segments with 
iSBG 300 module). These features 
allow the multi- 
processor systems to establish local memory for each 
processor and shared system (MULTIBUS)memory con- 
figurations where the total system memory size (includ- 
ing local on-board memory) can exceed 1 megabyte 
without addressing conflicts. 


EPROM Capabilities 


Four sockets are provided for up to 16K bytes of non· 
volatile read only memory on the iSBG 86/12A board. 
EPROM may be added in 2K-byte increments up to a 
maximum of 4K bytes by using Intel'" 2758 electrically 


programmable ROMs (EPROMs);in 4K-byte increments 
up to 8K bytes by using Intel 2716 EPROMs; or in 
8K-byte increments up to 16K bytes using Inel 2732 
EPROMs. On-board EPROM is accessed via 16-bit data 
paths. On-board EPROM capacity may be expanded to 
32K bytes with the addition of the iSBG 340 16K-byte 
MULTIMODUE EPROM option. It provides an additional 
four sockets for Intel 2732 EPROMs.With user modifica- 
tion of the iSBG 86/12A's on-board memory and MULlT- 
BUS address decode, Intel 2758 and 2716 EPROMs may 
be optionally supported. System memory size is easily 
expanded by the addition of MULTIBUS system bus 
compatible memory boards available in the iSBG prod- 
uct family. 


Parallel I/O Interface 


The iSSG 86/12A single board computer contains 24 
programmable parallel I/O lines implemented using the 
Intel 8255A Programmable 
Peripheral Interface. The 


system software is used to configure the I/O lines in any 
combination of unidirectional input/output and bidirec- 
tional 
ports indicated 
in Table 1. Therefore, the I/O 


interface may be customized to meet specific peripheral 
requirements. In order to take full advantage of the large 
number of possible 
I/O configurations, 
sockets are 


provided 
for interchangeable 
I/O line drivers 
and 


terminators. Hence, the flexibility of the I/O interface is 
further 
enhanced by the capability 
of selecting 
the 


appropriate 
combination 
of optional 
line drivers and 


terminators to provide the required sink current, polarity, 
and drive/termination 
charact€ristics for each applica- 


tion. The 24 'programmable I/O lines and signal ground 
lines are brought out to a 50-pin edge connector that 
mates with flat, woven, or round cable. 


Serial I/O 
A programmable communications 
interface using the 


Intel 8251A Universal 
Synchronous/Asynchronous 


Receiver/Transmitter (USART) is contained on the iSSG 
86/12A board. A software selectable baud rate generator 
provides the USART with all common communication 


Mode of Operation 


Unidirectional 
Lines 
Input 
Output 
Bidirectional 
Control 
Port 
(qty) 
Latched & 
Latched 
Latched & 
Latched 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
v,., 


3 
4 
X 
X 
Xl 


4 
X 
X 
X1 


~O~:rt 
of port 3 must 
be used as a control 
port when either 
port 1 or port 2 are used as a latched 
and strobed 
input 
or a latched 
and strobed 
output 


port or port 1 is used as a bidirectional 
port. 


synchronous 
serial data transmission 
technique 
(includ- 


ing ISM Si-Sync). 
The mode of operation 
(i.e., synchro- 
nous 
or asynchronous), 
data 
format, 
control 
character 


format, 
parity, 
and 
baud 
rate 
are 
all 
under 
program 


control. 
The 8251A provides 
full duplex, 
double 
buffered 


transmit 
and 
receive 
capability. 
Parity, 
overrun, 
and 


framing 
error 
detection 
are 
all 
incorporated 
in 
the 
USART. 
The 
RS232C 
compatible 
interface 
on 
each 


board. 
in conjunction 
with 
the USART, 
provides 
a direct 


interface 
to RS232C compatible 
terminals, 
cassettes, 
and 


asynchronous 
and synchronous 
modems. 
The RS232C 


command 
lines, serial data lines, and signal 
ground 
line 


are brought 
out to a 26 pin edge connector 
that mates with 


RS232C 
compatible 
flat or round 
cable. 
The 
iSSC 
530 
Teletypewnter 
Adapter 
provides 
an optically 
isolated 


interface 
for 
those 
systems 
requiring 
a 20 mA current 


loop. 
The iSSC 530 unit may be used to interface 
the iSSC 


86/12A 
board 
to teletypewriters 
or other 
20 mA current 


loop equipment. 


Programmable 
Timers 


The iSSC 86/12A board provides 
three independent, 
fully 
programmable 
16-bit 
interval 
timers/event 
counters 


utilizing 
the 
Intel 
8253 
Programmable 
Interval 
Timer. 


Each counter 
is capable 
of operating 
in either 
SCD or 


binary 
modes. 
Two of these timers/counters 
are available 


to 
the 
systems 
designer 
to 
generate 
accurate 
time 
intervals 
under software 
control. 
Routing 
for the outputs 
and gate/tngger 
inputs of two of these counters 
is jumper 


selectable. 
The outputs 
may be independently 
routed 
to 


the 8259A Programmable 
Interrupt 
Controller 
and to the 


I/O line drivers 
associated 
with the 8255A Programmable 


Peripheral 
Interface, 
or may be routed 
as inputs 
to the 


8255A chip. 
The gate/trigger 
inputs may be routed to I/O 


terminators 
associated 
with 
the 
8255A 
or 
as output 


connections 
from 
the 8255A. 
The third 
interval 
timer 
in 


the 8253 provides 
the programmable 
baud rate generator 


for the iSSC 86/12A board RS232C USART serial port. 
In 


utilizing 
the 
iSSC 
86/12A 
board 
the 
systems 
designer 


simply configures, 
via software, 
each timer independently 


to 
meet 
system 
requirements. 
Whenever 
a given 
time 


delay 
or count 
is needed, 
software 
commands 
to the 


programmable 
timers/event 
counters 
select 
the desired 


function. 
Seven 
functions 
are available, 
as shown 
in 


Table 2. The contents 
of each counter 
may be read at any 


time during 
system operation 
with simple read operations 


for event counting 
applications, 
and special 
commands 


are included 
so that the contents 
can be read "on the fly". 


MUL TIBUS 
System Bus and 


Multimaster 
Capabilities 


The MUl TISUS 
system 
bus features 
asynchronous 
data 


transfers 
for the accommodation 
of devices 
with various 


transfer 
rates 
while 
maintaining 
maximum 
throughput. 


Twenty 
address 
lines 
and 
sixteen 
separate 
data 
lines 


eliminate 
the need for address/data 
multiplexing/demul- 


tiplexing 
logic 
used in other 
systems, 
and allow 
for data 


transfer 
rates up to 5 megawords/sec. 
A failsafe 
timer 
is 


included 
in the iSSC 86/12A board which 
can be used to 


generate 
an interrupt 
if an addressed 
device 
does 
not 


respond 
within 
6 msec. 


Function 


Interrupt 
on 
terminal 
count 


Programmable 
one-shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When 
terminal 
count 
is 
reached, 


an interrupt 
request 
is generated. 


This 
function 
is extremely 
useful 


for generation 
of real-time 
clocks. 


Output 
goes 
low 
upon 
receipt 
of 


an 
external 
trigger 
edge 
or 
soft- 


ware 
command 
and 
returns 
high 
when 
terminal 
count 
is 
reached. 


This function 
is retriggerable. 


Divide 
by 
N counter. 
The 
output 


will 
go 
low 
for 
one 
input 
clock 


cycle, 
and the period 
from one low 


going 
pulse 
to the next 
is N times 


the input 
clock 
period. 


Output 
will 
remain 
high 
until 
one· 


half the count 
has been completed, 


and 
go 
low 
for 
the 
other 
half 
of 


the count. 


Output 
remains 
high 
until 
soft- 


ware 
loads 
count 
(N). N counts 
af- 


ter 
count 
is 
loaded, 
output 
goes 


low for one input 
clock 
period. 


Output 
goes 
low 
for 
one 
clock 


period 
N counts 
after 
rising 
edge 


counter 
trigger 
input. 
The counter 
is retriggerable. 


On a jumper 
selectable 
basis, 
the 


clock 
input 
becomes 
an 
input 


from 
the 
external 
system. 
CPU 


may 
read 
the 
number 
of 
events 


occurring 
after 
the counting 
"win- 


dow" 
has 
been 
enabled 
or 
an 


interrupt 
may be generated 
after 
N 


events 
occur 
in the system. 


Multimaster 
Capabilities 
- 
The 
iSSC 86/12A 
board 
is a 


full computer 
on a single board with resources 
capable 
of 


supporting 
a great variety 
of OEM system 
requirements. 


For those 
applications 
requiring 
additional 
processing 


capacity 
and the benefits 
of multiprocessing 
(i.e., several 


CPUs 
and/or 
controllers 
logically 
sharing 
system 
tasks 


through 
communication 
over the system 
bus), the iSSC 


86/12A board provides 
full MUl TISUS arbitration 
control 


logic. 
This control 
logic 
allows 
up to three 
iSSC 86/12A 


boards 
or other 
bus 
masters, 
including 
iSSC 
80 family 


MUl TISUS 
compatible 
8-bit 
single 
board 
computers, 
to 


share 
the 
system 
bus 
in serial 
(daisy 
chain) 
priority 


fashion 
and 
up to 16 masters 
to share 
the 
MUl TISUS 


system 
bus 
with 
the 
addition 
of an external 
priority 


network. 
The 
MUl TISUS 
arbitration 
logic 
operates 


synchronously 
with a MUl TISUS 
clock 
(provided 
by the 


iSSC 86/12A 
board 
or optionally 
provided 
directly 
from 


the MUl T1SUS) while data is transferred 
via a handshake 


between 
the 
master 
and 
slave 
modules. 
This 
allows 


different 
speed controllers 
to share resources 
on the same 


bus, and transfers 
via the bus proceed 
asynchronously. 


Thus, 
transfer 
speed 
is dependent 
on transmitting 
and 


receiving 
devices only. 
This design prevents slow master 


modules 
from being handicapped 
in their attempts to gain 


control 
of the bus, but does not restrict the speed at which 


faster 
modules 
can transfer 
data via the same bus. 
The 
most obvious 
applications 
for the master-slave 
capabili- 
ties of the bus are multiprocessor 
configurations, 
high 


speed peripheral 
control, 
but are by no means limited 
to 
these three. 


The 
iSSC 
86/12A 
board 
provides 
9 vectored 
interrupt 


levels. 
The 
highest 
level 
is the 
NMI 
(Non-maskable 
Interrupt) 
line which is directly 
tied to the 8086 CPU. 
This 
interrupt 
cannot 
be inhibited 
by software 
and is typically 
used 
for 
signalling 
catastrophic 
events 
(i.e., 
power 


failure). 
On servicing 
this interrupt, 
program 
control 
will 


be implicitly 
transferred 
through 
location 
00008H. 
The 


Intel 
8259A 
Programmable 
Interrupt 
Controller 
(PIC) 


provides 
vectoring 
for the next eight 
interrupt 
levels. 
As 
shown 
in Table 3, a selection 
of four priority 
processing 


modes 
is available 
to the systems 
designer 
for 
use in 


designing 
request 
processing 
configurations 
to 
match 


system 
requirements. 
Operating 
mode 
and 
priority 
assignments 
may 
be reconfigured 
dynamically 
via 


software 
at any time during 
system 
operation. 
The PIC 


accepts 
interrupt 
requests 
from 
the 
programmable 


parallel 
and 
serial 
I/O 
interfaces, 
the 
programmable 
timers, 
the 
system 
bus, 
or 
directly 
from 
peripheral 


equipment. 
The 
PIC 
then 
determines 
which 
of 
the 
incoming 
requests 
is of the highest 
priority, 
determines 
whether 
this 
request 
is of higher 
priority 
than the level 
currently 
being 
serviced, 
and, 
if appropriate, 
issues 
an 


interrupt 
to the CPU. 
Any combination 
of interrupt 
levels 


may be masked, 
via software, 
by storing 
a single 
byte in 
the interrupt 
mask register of the PIC. The PIC generates 


a unique 
memory 
address for each interrupt 
level. 
These 


addresses 
are equally 
spaced 
at 4 byte 
intervals. 
This 


32-byte 
block 
may begin at any 32-byte 
boundary 
in the 
lowest 
1K-bytes 
of 
memory: 
and 
contains 
unique 
instruction 
pointers 
and code segment 
offset values (for 
expanded 
memory 
operation) 
for 
each 
interrupt 
level. 


After 
acknowledging 
an interrupt 
and obtaining 
a device 


identifier 
byte from the 8259A PIC, the CPU will store its 


status 
flags on the stack 
and execute 
an indirect 
CALL 


instruction 
through 
the vector 
location 
(derived from the 


device 
identifier) 
to 
the 
interrupt 
service 
routine. 
In 


systems 
requiring 
additional 
interrupt 
levels, slave 8259A 


PIC's may be interfaced 
via the MUL TISUS 
system 
bus, 
to generate 
additional 
vector 
addresses, 
yielding 
a total 


of 65 unique 
interrupt 
levels. 


Interrupt Request Generation - 
Interrupt 
requests 
may 


originate 
from 
18 
sources. 
Two 
jumper 
selectable 


interrupt 
requests 
can 
be automatically 
generated 
by 


the 
programmable 
peripheral 
interface 
when 
a byte 
of 


'Note: The first 32 vector 
locations 
are reserved 
by Intel 


for 
dedicated 
vectors. 
Users 
who 
wish 
to 
maintain 


compatibility 
with 
present 
and 
future 
Intel 
products 


should 
not 
use these 
locations 
for user-defined 
vector 


addresses. 


Mode 
Operation 


Fully 
nested 
Interrupt 
request 
line 
priorities 


fixed 
at 0 as highest, 
7 as lowest. 


Auto-rotating 
Equal 
priority. 
Each 
level, 
after 


receiving 
service, 
becomes 
the 


lowest 
priority 
level 
until 
next 
in- 


terrupt 
occurs. 


Specific 
System 
software 
assigns 
lowest 


priority 
priority 
level. 
Priority 
of 
all 
other 


levels 
based 
in sequence 
numeri- 


cally on this assignment. 


Polled 
System 
software 
examines 
priori- 


ty-encoded 
system 
interrupt 
status 


via interrupt 
status 
register. 


information 
is ready 
to be transferred 
to the CPU 
(i.e., 


input 
buffer 
is full) 
or a byte 
of information 
has been 


transferred 
to a peripheral 
device 
(i.e., output 
buffer 
is 


empty). 
Two jumper 
selectable 
interrupt 
requests can be 


automatically 
generated 
by the USART when a character 


is ready to be transferred 
to the CPU (i.e., receive channel 


buffer is full, or a character 
is rElady to be transmitted 
(i.e., 


transmit 
channel 
data 
buffer 
is empty). 
A jumper 


selectable 
request 
can 
be generated 
by each 
of the 


programmable 
timers. 
An additional 
interrupt 
request 


line may be jumpered 
directly 
from the parallel 
I/O driver 


terminator 
section. 
Eight 
prioritized 
interrupt 
request 


lines 
allow 
the 
iSSC 
86/12A 
board 
to 
recognize 
and 


service 
interrupts 
originating 
from 
peripheral 
boards 


interfaced 
via the 
MUL TIBUS 
system 
bus. The MULTI- 


BUS fail safe timer 
of the iSSC 337 processor 
and the 


exception 
and error output 
signal 
also can be selected 


as interrupt 
sources. 


Control 
logic 
is also 
included 
to 
accept 
a power-fail 
interrupt 
in conjunction 
with the AC-Iow 
signal 
from the 


iSSC 635 and iSSC 640 Power Supply 
or equivalent. 


Expansion Capabilities 


Memory 
and 
I/O 
capacity 
may 
be 
expanded 
and 


additional 
functions 
added 
using 
Intel 
MUL TISUS 
compatible 
expansion 
boards. 
Memory may be expanded 


by adding 
user specified 
combinations 
of RAM boards, 


EPROM 
boards, 
or combination 
boards. 
Input/output 
capacity 
may 
be increased 
by adding 
digital 
I/O 
and 


analog 
I/O 
expansion 
boards. 
Mass 
storage 
capability 


may 
be achieved 
by 
adding 
single 
or 
double 
density 


diskette 
controllers, 
or 
hard 
disk 
controllers. 
Modular 


expandable 
backplanes 
and cardcages 
are available 
to 


support 
multiboard 
systems. 


Note: Certain 
system restrictions 
may be incurred 
by the 
inclusion 
of some of the iSSC 80 family options 
in an iSSC 


86/12A 
system. 
Consult 
the 
Intel 
OEM 
Microcomputer 


System 
Configuration 
Guide 
for specific 
data. 


intel 


System Development 
Capabilities 


The development cycle of iSSC 86/12A products can be 
significantly 
reduced by using the Intellec" 
series 
microcomputer 
development system. The Assembler, 


High Level Languages, Locating Linker, Library Man- 
ager, Text Editor and System Monitor are all supported 
by the ISIS-II disk-based operating system. 


In-Circuit Emulator - 
ICpM-86 in-circuit emulator pro- 


vides the necessary link between the software develop- 
ment environment provided by the Intellec system and 
the "target" 
iSSC 86/12A execution system. In addition 


to providing the mechanism for loading executable code 
and data into the iSSC 86/12A board, ICE-86 in-circuit 
emulator provides a sophisticated command set to assist 
in debugging software and final integration of the user 
hardware and software. ICE-86 in-circuit emulator max- 
imizes the use of available development resources by 


aliowing Intellec resident resources (e.g., memory and 
peripherals) to be accessed by software running on the 
target iSSC 86/12A system. In addition, software can be 
executed without an iSSC 86/12Aexecution vehicle, in 2K 
bytes of RAM resident in the ICE-86 system itself. Sym- 
bolic references to instruction and data locations can be 
madethrough ICE-86 in-circuit emulator to allow the user 
to reference memory locations with assigned ~ames. 


PL/M-86 - 
Intel's high level programming language, 


PL/M-86, is also available as an Intellec Microcomputer 
Development System option. 
PL/M-86 provides the 


capability to program in a natural, aigorithmic language 
and eliminates the need to manage register usage or 
allocate memory. PLlM-86 programs can be written in a 
much shorter time than assembly language programs for a 
given application. 
PLlM-86 
includes 
byte and word, 


integer, pointer and floating point (32-bit) data types and 
also includes conditional compilation and macro features. 


Word Size 
Instruction 
- 
8,16,24, or 32 bits 
Data - 
8, 16 bits 


Cycle Time 
Basic Instruction Cycle 
1.2/-lsec 
400 nsec (assumes 
instruction in the queue) 


Note: 
Basic instruction 
cycle 
is defined 
as the fastest 
instruction 
time (Le., 


two clock cycles) 


Memory Capacity 
On-Board Read Only Memory - 
16K bytes (sockets 
only); expandable to 32K bytes with iSSC 340 16K-byte 
MULTIMODULE EPROM option. 


On-Board RAM - 
32K bytes; expandable to 64K bytes 


with iSSC 300 32K-byte MULTIMODULE RAM option, 


Off-Board Expandlon - 
Up to 1 megabyte in user speci- 


fied combinations of RAM and EPROM. 


Memory Addressing 


On-Board 
EPROM - 
FFOOO-FFFFFH (using 
2758 


EPROMs); 
FEOOO-FFFFFH (using 
2716 
EPROMs); 


FCOOO-FFFFFH(using 2732 EPROMS);F8000-FFFFFH 
(With iSSC 340 EPRO,Moption and four additional 2732 
EPROMs). 


On-Board RAM - 
32K bytes of dual port RAM. Option- 
ally expandable to 64K bytes with iSSC 300 RAM option. 


CPU Access - 
32K bytes: 00000-07FFFH; 64K bytes: 
OOOOO-OFFFFH. 


MULTIBUS Access - 
Jumper selectable for any 8K-byte 


boundary, but not crossing a 128K-byte boundary. Ac- 
cess for 8K, 16K, 24K or 32K (16K, 32K, 4-8K,64K with 
iSSC 300 option) bytes may be selected for on-board 
CPU use only. 


110 Capacity 
Parallel - 
24 programmable lines using one 8255A. 


Serial - 
1 programmable line using one 8251A. 


1/0 Addressing 
On-Board Programmable I/O 


Control 


CE 


Data 


DB or 


DC 


Control 


OA or 
DE 


1 


Address 
C8 


Serial Communications 
Characteristics 


Synchronous - 
5-8 
bit characters; internal or exter- 


nal character synchronization; automatic sync insertion. 


Asynchronous 
- 
5-8 
bit characters; break character 


generation; 
1, 1V2, 
or 
2 stop 
bits; 
false 
start 
bit 


detection. 


Baud Rates 


Frequency 
(kHz) 
Baud Rate (Hz) 


(Software 
Selectable) 
Synchronous 
Asynchronous 


+ 16 
+ 64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


Nole: 
Frequency 
selected 
by 110 write of appropriate 
16-bit frequency 
factor 


to baud rate register 
(8253 Timer 
2). 


inter 


Interrupts 
Addresses for 8259A Registers (Hex notation 
1/0 
ad- 


dress space) 
COor C4 
Write: Initialization Command Word 1 (ICW1) 


and Operation Control Words 2 and 3 
(OCW2and OCW3) 


Read: Status and Poll Registers 


C20rC6 
Write: ICW2, 
ICW3, ICW4, OCW1 (Mask 
Register) 
Read: OCW1(MaskRegis~er) 


Note: 
Several 
registers 
have the same 
physical 
address; 
sequence 
of access 
and one data bit of control 
word determine 
which 
register 
will 
respond. 


Interrupt Levels - 
8086 CPU includes a non-maskable 
Interrupt (NMI) and a maskable interrupt (INTR). NMI 
interrupt is provided for catastrophic events such as 
power failure. NMI vector addressis00008.INTRinterrupt 
is driven by on-board 8259A PIC, which provides 8-bit 
identifier of interrupting device to CPU. CPU multiplies 
identifier by four to derive vector address.Jumpers select 
interrupts from 18sources without necessity of external 
hardware. PIC May be programmed to accommodate 
edge-sensitive or level-sensitive inputs. 


Timers 


Register Addresses (Hex notation, I/O address space) 


00 
Timer 0 
02 
Timer 1 
04 
Timer 2 
06 
Control register 


Note: 
Timer counts are loaded as two sequential output operations to same 
address as given. 


Input Frequencies 
Ref~rence: 2.46 MHz ±0.1% (0.041",s period, nominal); 
1.23 MHz ±0.1% 
(0.81 /-,S period, nominal); or 153.60 


kHz ± 0.1% (6.51 "'S period nominal). 


Note: 
Above 
frequencies 
are user selectable. 


Event Rate: 2.46 MHz max 


Output Frequencies/Timing Intervals 


Single 
Timer/Counter 
Dual Timer/Counter 


Function 
(Two Timers 
Cascadad) 


Min 
Max 
Min 
Ma. 


Real-time 
1.63~s 
427.1 ms 
3.26 
s 
466.50 min 


interrupt 


Programmabl~ 
1.63 ~s 
427.1 ms 
3.26 
s 
466.50 min 


one-shot 


Rate generator 
2.342 Hz 
613.5 kHz 
0.000036 
Hz 
306.8 kHz 


Square-wave 
2.342 Hz 
613.5 kHz 
0.000036 
Hz 
306.8 kHz 


rate generator 


Software 
1.63~s 
427.1 ms 
3.26 
s 
466.50 min 


triggered 
strobe 


Hardware 
1.63 ~s 
427.1 ms 
3.26 
s 
466.50 min 


triggered 
strobe 


Event 
- 
2.46 MHl 
- 
- 


counter 


Interfaces 
MULTIBUS - 
All signals TIL compatible 
Parallel I/O - 
All signals TIL compatible 
Interrupt Requests - 
All TIL compatible 
Timer - 
All signals TTL compatible 
Serial I/O - 
RS232Ccompatible, data set configuration 


System Clock (8086 CPU) 
5.00 MHz ± 0.1% 


Auxiliary 
Power 
An auxiliary power bus is provided to allow separate 
power to RAM for systems requiring battery backup of 
read/write 
memory. Selection 
of this auxiliary 
RAM 


power bus is made via jumpers on the board. 


Interface 
Pins 
Centers 
Mating 
Connectors 


(qty) 
(in.) 


Bus 
86 
·0.156 
VIKING 
3KH43/9AMK12 


Paraliell/O 
50 
0.1 
3M 3415-000 


Serial 
110 
26 
0.1 
3M 3462·000 


Memory Protect 
An active low TIL compatible memory protect signal is 
brought out on the auxiliary connector which, when 
asserted, disables read/write access to RAM memory 
on the board. This input is provided for the protection 
of RAM contents during system power down sequences. 


Line Drivers and Terminators 
I/O Drivers - 
The following line drivers are air compatible 


with the I/O driver sockets on the iSBC 86/12A board 


Driver 
Characteristic 
Sink Currant 
(mA) 


7438 
I,OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


Port 1 of the 8255A has 20 mA totem-pole bidirectional 
drivers and 1 kQterminators. 


I/O Terminators - 
220Q/330Qdivider or 1 kQpuliup 


2200/3300 
(ISSC 901 OPTION) 


220Q 
+5V_; 
L 
330Q 
.l~--- 
---~ 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-state 
50 
Address 
Tri-state 
50 
Commands 
Tri-state 
32 


Physical Characteristics 
Width 
- 
12.00 in. (30.48 cm) 
Height 
- 
6.75 in. (17.15 cm) 
Depth - 
0.70 in. (1.78 cm) 


Weight 
- 
19 oz. (539 gm) 


Electrical 
Characteristics 


DC Power Requirements 


Current 
Requirements 


Contigu- 
VCC=+5V 
VOO = +12V 
VBB = 
-5V 
VAA=-12V 


ration 
+ 5% (max) 
+5% 
(max) 
::!:: 5% (max) 
:5% 
(max) 


Without 
5.2A 
350 mA 
- 
40 mA 
EPROM' 


RAM Only3 
390 mA 
40 mA 
1.0mA 
- 


With 
5.2A 
450 mA 
- 
140 mA 
iSSC 53Q4 


With4K 
EPROM' 
5.5A 
350 mA 
- 
40 mA 


(using 
2758) 


With8K 
EPROM' 
5.5A 
350 mA 
- 
40 mA 
(using 
2716) 


With 
16K 
EPROM' 
5.4A 


I 


350 mA 
- 
40 mA 
(using 
2732) 


Nol •• : 


1, Does not include 
power 
for optional 
EPROM, 
110 drivers, 
and 110ter- 
minators. 


2. Does not include 
power reQuired for optional 
EPROM, 
110 drivers, 
and 


110 terminators. 


3. RAM chips 
powered 
via aU,Xiliary power 
bus. 


4. Does not include 
power 
for optional 
EPROM, 
1/0 drivers, 
and 110 ter- 
minators. 
Power 
for iSBC 530 is supplied 
via serial 
port connector. 


5. Includes 
power 
required 
for four 
EPROM 
chips. 
and 110 terminators 


installed 
fo"16 
110 lines; 
all terminator 
inputs 
low. 


Environmental 
Characteristics 
Operating Temperature 
- 
O°C to 55°C 


Relative Humidity 
- 
to 90% (without condensation) 


Reference Manual 


9803074·01 - 
iSBC 86/12A Single 
Board Computer 


Hardware Reference Manual (NOT SUPPLIED) 


Reference manuals are shipped with each product only if 
designated 
SUPPLIED (see above). Manuals may be 
ordered 
from 
any Intel Literature 
Department, 
3065 


Bowers Avenue, Santa Clara, California 95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SBC 86/12A 
Single Board Computer 
with 32K bytes RAM 


iSBC 86/05™ 


SINGLE 
BOARD COMPUTER 


• iAPX 86/10 (8086-2) Microprocessor 


with 5 or 8 MHz CPU clock 


• Fully software compatible 
with iSBC 


86/12A Single Board Computer 


• Optional iAPX 86/20 Numeric Data 


Processor with iSBC 337 
MUL TIMODULE 
Processor 


• 8K bytes of static RAM; expandable 


on-board to 16K bytes 


• Sockets for up to 64K bytes of JEDEC 


24/28-pin standard memory devices; 
expandable on-board to 128K bytes 


• Two iSBX™ bus connectors 


• 24 programmable 
parallel I/O lines 


• Programmable 
synchronous/asynchro- 


nous RS232C compatible 
serial 
inter- 


face with software selectable baud 
rates 


• Two programmable 16-bit BCD or binary 


timers/event counters 


• 9 Levels of vectored interrupt control, 


expandable to 65 levels 


• MULTIBUS interface for multi master 


configurations 
and system expansion 


• Supported by a complete family of 


single board computers, memory, 
digital and analog I/O, peripheral 
controllers, packaging and software 


The iSBC 86/05 Single 
Board Computer 
is a member of Intel's 
complete 
line of OEM microcomputer 
sys- 


tems which 
take full advantage 
of Intel's 
technology 
to provide 
economical, 
self-contained, 
computer- 


based solutions 
for OEM applications. 
The iSBC 86/05 board is a complete 
computer 
system on a single 
6.75 x 12.00-in. printed 
circuit 
card. The CPU, system 
clock, 
read/write 
memory, 
nonvolatile 
read only 


memory, 
I/O ports and drivers, serial communications 
interface, 
priority 
interrupt 
logic and programmable 
timers, 
all reside 
on the board. The large control 
storage 
capacity 
makes the iSBC 86/05 board 
ideally 


suited 
for control-oriented 
applications 
such as process 
control, 
instrumentation, 
industrial 
automation, 


and many others. 


Central Processing Unit 


The central 
processor 
for the iSBC 86/05 board is 
Intel's 
iAPX 86/10 (8086-2) CPU. A clock 
rate of 8 
MHz is supported 
with a jumper 
selectable 
option 
of 
5 MHz. 
The 
CPU architecture 
includes 
four 


16-bit byte addressable 
data registers, 
two 16-bit 


memory 
base pointer 
registers 
and two 16-bit in- 
dex registers, 
all accessed 
by a total of 24 operand 
addressing 
modes for comprehensive 
memory ad- 
dressing 
and for support 
of the data structures 


required 
for 
today's 
structured, 
high 
level 
lan- 
guages as well as assembly 
language. 


Instruction Set 


The 8086 instruction 
repertoire 
includes 
variable 


length 
instruction 
format 
(including 
double 
oper- 


and instructions), 
8-bit and 16-bit signed 
and un- 


signed 
arithmetic 
operators 
for binary, 
BCD and 


unpacked 
ASCII data, and iterative 
word and byte 


string 
manipulation 
functions. 


For enhanced 
numerics 
processing 
capability, 
the 


iSBC 337 MULTIMODULE 
Numeric 
Data Proces- 


sor extends 
the iAPX 86/10 architecture 
and data 


set. Over 60 numeric 
instructions 
offer arithmetic, 


trig~nometric, 
transcendental, 
logarithmic 
and ex- 


ponential 
instructions. 
Supported 
data 
types 
in- 
clude 
16, 32, and 64-bit integer, 
and 32 and 64-bit 


floating 
point, 18-digit packed BCD and 80-bit tem- 


porary. 


Architectural 
Features 


A 6-byte 
instruction 
queue 
provides 
pre-fetching 
of sequential 
instructions 
and can reduce the 750 
nsec 
minimum 
instruction 
cycle 
to 250 nsec for 


queued 
instructions. 
The stack-oriented 
architec- 


ture 
readily 
supports 
modular 
programming 
by 


facilitating 
fast, simple, 
inter-module 
communica- 


tion, 
and other 
programming 
constructs 
needed 


for asynchronous 
real-time 
systems. 
The memory 
expansion 
capabilities 
offer 
a 
1 megabyte 
ad- 


dressing 
range. The dynamic 
relocation 
scheme 
allows 
ease 
in segmentation 
of pure 
procedure 


and 
data 
for 
efficient 
memory 
utilization. 
Four 


segment 
registers 
(code, 
stack, 
data, extra) con- 


tain program 
loaded offset 
values which 
are used 


to map 16-bit addresses 
to 20-bit addresses. 
Each 


register 
maps 64K bytes at a time and activation 
of 


a specific 
register 
is controlled 
explicitly 
by pro- 


gram 
control 
and 
is also 
selected 
implicitly 
by 


specific 
functions 
and instructions. 
All Intel 
lan- 


guages 
support 
the extended 
memory 
capability, 


relieving 
the programmer 
of managing 
the mega- 


byte memory 
space, yet allowing 
explicit 
control 


when necessary. 


81< BYTES 
RAM 
: 


IlSBC302) 
I 


I 
(".21M) 
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Memory 
Configuration 


The iSBC 86/05 microcomputer 
contains 
8K bytes 
of 
high-speed 
static 
RAM 
on-board. 
In addition, 
the on-board 
RAM may be expanded 
to 16K bytes 
with 
the 
iSBC 
302 
MUL TIMODULE 
RAM 
option 
which 
mounts 
on 
the 
iSBC 
86/05 
board. 
All 
on- 
board 
RAM is accessed 
by the 8086-2 CPU with 
no 
wait 
states, 
yielding 
a memory 
cycle 
time 
of 500 
nsec. 


In addition 
to the 
on-board 
RAM, 
the 
iSBC 
86/05 
board 
has four 
28-pin 
sockets, 
configured 
to ac- 
cept 
JEDEC 
24/28-pin 
standard 
memory 
devices. 


Up 
to 
64K 
bytes 
of 
EPROM 
are 
supported 
in 
16K-byte 
increments 
with 
Intel 
27128 
EPROMs. 
The 
iSSC 
86/05 
board 
is also 
compatible 
with 
the 
2716, 2732A, 
and 2764 EPROMs 
offering 
expansion 
to 8,16 
and 32K bytes, 
respectively. 


With 
the addition 
of the iSBC 341 MULTIMODULE 
EPROM 
option, 
the 
on-board 
capacity 
for 
these 
devices 
is doubled, 
providing 
up to 128K bytes 
of 
EPROM 
capacity 
on-board. 


Parallel 
110Interface 


The 
iSBC 
86/05 Single 
Board 
Computer 
contains 
24 programmable 
parallel 
I/O lines 
implemented 
using 
the 
Intel 
8255A 
Programmable 
Peripheral 
Interface. 
The system 
software 
is used 
to config- 
ure the 
I/O lines 
in any 
combination 
of unidirec- 


tional 
input/output 
and 
bidirectional 
ports 
indi- 
cated 
in Table 
1. In order 
to take advantage 
of the 
large number 
of possible 
I/O configurations, 
sock- 
ets 
are 
provided 
for 
interchangeable 
I/O 
line 


drivers 
and 
terminators, 
allowing 
the 
selection 


of 
the 
appropriate 
combination 
of 
optional 
line 


drivers 
and 
terminators 
with 
the 
required 
drive/ 


termination 
characteristics. 
The 24 programmable 


I/O lines 
and 
signal 
ground 
lines 
are brought 
out 


to a 50-pin 
edge 
connector. 


A programmable 
communications 
interface 
using 


the 
Intel 
8251A 
Universal 
Synchronous/Asynchro- 


nous 
Receiver/Transmitter 
(USART) 
is contained 


on 
the 
iSBC 
86/05 
board. 
A software 
selectable 


baud 
rate 
generator 
provides 
the 
USART 
with 
all 


common 
communication 
frequencies. 
The 
mode 


of operation 
(Le., synchronous 
or asynchronous), 


data 
format, 
control 
character 
format, 
parity, 
and 


baud rate are all under 
program 
control. 
The 8251A 


provides 
full duplex, 
double 
buffered 
transmit 
and 


receive 
capability. 
Parity, 
overrun, 
and 
framing 


error 
detection 
are all incorporated 
in the USART. 


The RS232C 
compatible 
interface 
on each 
board, 


in conjunction 
with 
the 
USART, 
provides 
a direct 


interface 
to RS232C compatible 
terminals, 
casset- 


tes, and asynchronous 
and synchronous 
modems. 


The RS232C 
command 
lines, 
serial 
data 
lines 
and 


signal 
ground 
line are brought 
out to a 26-pin 
edge 


connector. 


Programmable 
Timers 


The iSBC 86/05 board 
provides 
three 
independent, 


fully 
programmable 
16-bit 
interval 
timers/event 


counters 
utilizing 
the 
Intel 
8253 
Programmable 


Mode 
of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
(qty) 
Control 
Bidirectional 


Latched 
Latched 
& 
Latched 
Latched 
& 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X' 


4 
X 
X 
X' 


NOTE: 
1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed input or a latched and 


strobed output port or port 1 is used as a bidirectional 
port. 


Interval 
Timer. 
Each counter 
is capable 
of oper- 
ating in either 
BCD or binary modes. Two of these 


timers/counters 
are available 
to the systems 
de- 
signer 
to generate 
accurate 
time 
intervals 
under 


software 
control. 
Routing 
for 
the 
outputs 
and 


gate/trigger 
inputs 
of" two 
of these 
counters 
is 


jumper 
selectable. 
The outputs 
may be indepen- 


dently 
routed 
to the 8259A 
Programmable 
Inter- 
rupt Controller 
and to the I/O terminators 
associ- 


ated with the 8255A to allow external 
devices or an 


8255A port to gate the timer 
or to count 
external 


events. 
The third 
interval 
timer 
in the 8253 pro- 
vides 
the programmable 
baud 
rate generator 
for 


the iSBC 86/05 board RS232C USART serial 
port. 


The system 
software 
configures 
each timer 
inde- 
pendently 
to select 
the desired 
function. 
Seven 


functions 
are available 
as shown 
in Table 2. The 


contents 
of each counter 
may be read at any time 


during 
system 
operation. 


Function 


Interrupt on 
terminal count 


Programmable 
one-shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When terminal count is reached,an 
interrupt request is generated. This 
function 
is extremely. useful 
for 


generation of real-time clocks. 


Output goes low upon receipt of an 
external trigger edge or software 
command and returns high when 
terminal 
count 
is 
reached. This 


function is retriggerable. 


Divide by N counter. The output 
will 
go low for one input clock 


cycle, and the period from one low 
going pulse to the next is N times 
the input clock period. 


Output will remain high until one· 
half the count has been completed, 
and go low for the other half of the 
count. 


Output remains high until software 
loads count (N). N counts after 
count is loaded, output goes low 
for one input clock period. 


Output 
goes low for 
one clock 
period N counts after rising edge 
counter trigger input. The counter 
is retriggerable. 


On a jumper selectable basis, the 
clock input becomes an input from 
the external system. CPU may read 
the number of 
events occurring 


after 
the counter 
"window" 
has 


been enabled or an interrupt may 
be generated after N events occur 
in the system. 


iSBX MULTIMODULE 
On·Board 


Expansion 


Two 8/16-bit iSBX MULTIMODULE 
connectors 
are 


provided 
on 
the 
iSBC 
86/05 
microcomputer. 


Through 
these 
connectors, 
additional 
on-board 


I/O functions 
may 
be added. 
iSBX 
MULTIMOD- 


ULES 
optimally 
support 
functions 
provided 
by 


VLSI 
peripheral 
components 
such 
as additional 


parallel 
and 
serial 
I/O, analog 
I/O, small 
mass 


storage 
device 
controllers 
(e.g., 
cassettes 
and 


floppy disks), and other custom 
interfaces 
to meet 


specific 
needs. By mounting 
directly 
on the single 


board computer, 
less interface 
logic, 
less power, 


simpler 
packaging, 
higher performance, 
and lower 


cost 
result 
when 
compared 
to other 
alternatives 


such 
as 
MULTI BUS 
form 
factor 
compatible 


boards. 
The iSBX connectors 
on the iSBC 86/05 


provide 
all signals 
necessary 
to interface 
to the 
. local 
on-board 
bus, 
including 
16 data 
lines 
for 


maximum 
data 
transfer 
rates. 
iSBX 
MULTIMOD- 


ULE boards 
designed 
with 
8-bit 
data 
paths 
and 


using the 8-bit iSBX connector 
are also supported 


on the iSBC 86/05 microcomputer. 
A broad range 


of iSBX MUL TIMODULE 
options 
are available 
in 


this family 
from Intel. Custom 
iSBX modules 
may 


also be designed 
for use on the iSBC 86/05 board. 


An iSBX bus interface 
specification 
and iSBX con- 


nectors 
are available 
from 
Intel. 


MULTIBUS™ SYSTEM BUS AND 
MULTIMASTER 
CAPABILITIES 


Overview 


The 
MUL TIBUS 
system 
bus 
is 
Intel's 
industry 


standard 
microcomputer 
bus 
structure. 
Both 
8 


and 16-bit single 
board computers 
are supported 


on the MUL T1BUS structure 
with 
24 address 
and 


16 data 
lines. 
In 
its 
simplest 
application, 
the 


MUL T1BUS system 
bus allows 
expansion 
of func- 


tions 
already 
contained 
on a single 
board 
com- 


puter (e.g., memory 
and digital 
I/O). However, 
the 


MUL TIBUS 
structure 
also 
allows 
very 
powerful 


distributed 
processing 
configurations 
with 
multi- 


ple 
processors 
and 
intelligent 
slave 
I/O, 
and 


peripheral 
boards 
capable 
of 
solving 
the 
most 


demanding 
microcomputer 
applications. 
The 


MULTIBUS 
system 
bus is supported 
with a broad 


array of board 
level products, 
LSI interface 
com- 


ponents, 
detailed 
published 
specifications 
and 


application 
notes. 


Expansion Capabilities 


Memory 
and I/O capacity 
may be expanded 
and 


additional 
functions 
added using 
Intel MULTI BUS 


compatible 
expansion 
boards. 
Memory 
may 
be 


expanded 
by adding 
user specified 
combinations 


of RAM boards, 
EPROM boards, 
or combination 


boards. Input/output 
capacity 
may be added with 


digital 
I/O and analog I/O expansion 
boards. Mass 


storage 
capability 
may 
be achieved 
by adding 


single 
or double 
density 
diskette 
controllers, 
or 


hard disk 
controllers. 
Modular 
expandable 
back- 
planes 
and 
cardcages 
are available 
to 
support 


multiboard 
systems. 


Multimaster 
Capabilities 


For those 
applications 
requiring 
additional 
pro- 


cessing 
capacity 
and 
the 
benefits 
of 
multi- 
processing 
(i.e., several 
CPUs and/or 
controllers 


logically 
sharing 
system tasks through 
communi- 


cation 
of the system 
bus), the iSBC 86/05 board 


provides 
full 
MULTIBUS arbitration 
control 
logic. 


This control 
logic 
allows 
up to three 
iSBC 86/05 


boards 
or other 
bus masters, 
including 
iSBC 80 


family 
MUL TIBUS compatible 
8-bit 
single 
board 


computers 
to share the system 
bus using a serial 


(daisy chain) priority 
scheme 
and allows 
up to 16 


masters 
to share the MULTIBUS system 
bus with 


an external 
parallel 
priority 
decoder. 
In addition 
to 


the multiprocessing 
configurations 
made 
possi- 


ble with multimaster 
capability, 
it also provides 
a 


very efficient 
mechanism 
for all forms 
of 
DMA 


(Direct 
Memory Access) 
transfers. 


Interrupt Capability 


The iSBC 86/05 board 
provides 
9 vectored .inter- 


rupt 
levels. 
The highest 
level 
is the 
NMI (Non- 
Maskable 
Interrupt) 
line which 
is directly 
tied to 


the 8086 CPU. This interrupt 
is typically 
used for 


signaling 
catastrophic 
events (e.g., power failure). 


The 
Intel 
8259A 
Programmable 
Interrupt 
Con- 
troller 
(PIC) provides 
control 
and vectoring 
for the 


next eight interrupt 
levels. As shown in Table 3, a 


selection 
of 
four 
priority 
processing 
modes 
is 


available 
for use in designing 
request 
processing 


configurations 
to match system 
requirements 
for 


efficient 
interrupt 
servicing 
with 
minimal 
laten- 
cies. 
Operating 
mode 
and 
priority 
assignments 


may be reconfigured 
dynamically 
via software 
at 


any time 
during 
system 
operation. 
The PIC ac- 


cepts 
interrupt 
requests 
from 
all 
on-board 
I/O 


resources 
and from 
the MUL TIBUS system 
bus. 
The PIC then resolves 
requests 
according 
to the 


selected 
mode and, if appropriate, 
issues an inter- 
rupt 
to 
the 
CPU. Any 
combination 
of 
interrupt 


levels 
may be masked 
via software, 
by storing 
a 


single 
byte in the interrupt 
mask register 
of the 


PIC. 
In 
systems 
requiring 
additional 
interrupt 


levels, slave 8259A PICs may be interfaced 
via the 


MUL TIBUS 
system 
bus, 
to 
generate 
additional 


vector 
addresses, 
yielding 
a total 
of 65 unique 


interrupt 
levels. 


Mode 
I 
Operation 


Fully nested 
Interrupt request line priorities fixed 
at 0 as highest, 7 as lowest. 


Auto-rotating 
Equal priority. Each level, after re- 
ceiving service, becomes the lowest 
priority level until next interrupt oc- 
curs. 


Specific 
System 
software 
assigns 
lowest 


priority 
priority 
level. Priority 
of all other 


levels based in sequence numeric- 
ally on this assignment. 


Polled 
System software examines priority- 
encoded system interrupt status via 
interrupt status register. 


Interrupt Request Generation 


Interrupt 
requests 
to 
be serviced 
by the 
iSBC 


86/05 board may originate 
from 24 sources. 
Table 


4 includes 
a list 
of devices 
and functions 
S.UP- 


ported 
by 
interrupts. 
All 
interrupt 
signals 
are 


brought 
to the interrupt 
jumper 
matrix 
where any 


combination 
of interrupt 
sources may be strapped 


to the desired interrupt 
request level on the 8259A 


PIC or the NMI input to the CPU dir!3ctly. 


Power-Fail Control and Auxiliary Power 


Control 
logic 
is also included 
to accept 
a power- 


fail interrupt 
in conjunction 
with the AC-Iow signal 


from the iSBC 635 and iSBC 640 Power Supply or 
equivalent, 
to initiate 
an orderly 
shut down of the 


system 
in the event of a power failure. 
Addition- 


ally, an active-low 
TIL compatible 
memory protect 


signal 
is brought 
out on the auxiliary 
connector 


which, 
when asserted, 
disables 
read/write 
access 


to RAM memory 
on the board. This 
input 
is pro- 


vided for the protection 
of RAM contents 
during 


system 
power-down 
sequences. 
An 
auxiliary 


power 
bus 
is 
also 
provided 
to 
allow 
separate 


power to RAM for systems 
requiring 
battery back- 


up of read/write 
memory. 
Selection 
of this 
auxil- 


iary RAM power 
bus is made via jumpers 
on the 


board. 


System Development Capabilities 


The development 
cycle 
of 
iSBC 86/05 products 


can 
be significantly 
reduced 
and 
simplified 
by 


using the Intellec 
Series Microcomputer 
Develop- 
ment 
Systems. 
The Assembler, 
Locating 
Linker, 
Library 
Manager, Text Editor and System 
Monitor 
are all supported 
by the ISIS-II disk-based 
operat- 


ing 
system. 
To 
facilitate 
conversion 
of 
8080A/ 
8085A assembly 
language 
programs 
to run on the 


iSBC 86/05 board, CONV-86 is available 
under the 


ISIS-II operating 
system. 


IN-CIRCUIT 
EMULATOR 


The 
ICE-86 
In-Circuit 
Emulator 
provides 
the 
necessary 
link between 
the software 
development 
environment 
provided 
by the Intellec 
system 
and 
the "target" 
iSBC 86/05 execution 
system. 
In addi- 
tion 
to providing 
the mechanism 
for loading 
exe- 
cutable 
code and data into the iSBC 86/05 board, 
the ICE-86 In-Circuit 
Emulator 
provides 
a sophis- 


ticated 
command 
set to assist 
in debugging 
soft- 
ware 
and final 
integration 
of the 
user 
hardware 
and software. 


Intel's 
system's 
implementation 
language, 


PUM-86, is also available 
as an Intellec 
Microcom- 
puter 
Development 
System 
option. 
PUM-86 
pro- 


vides 
the 
capability 
to 
program 
in 
algorithmic 


language 
and eliminates 
the need to manage reg- 


ister usage or allocate 
memory 
while still allowing 
explicit 
control 
of the system's 
resources 
when 
needed. 


Run·Time Support 


Intel 
also offers 
two 
run-time 
support 
packages; 


iRMX 88 Realtime 
Multitasking 
Executive 
and the 
iRMX 86 Operating 
System. 
iRMX 88 is a simple, 


highly 
configurable 
and efficient 
foundation 
for 
small, 
high 
performance 
applications. 
Its 
multi- 


tasking 
structure 
establishes 
a solid 
foundation 


for 
modular 
system 
design 
and 
provides 
task 


scheduling 
and management, 
intertask 
communi- 
cation 
and synchronization, 
and interrupt 
servic- 


ing for a variety 
of peripheral 
devices. 
Other con- 


figurable 
options 
include 
terminal 
handlers, 
disk 


file system, 
debuggers 
and other utilities. 
iRMX 86 
is a high functional 
operating 
system 
with a very 


rich 
set 
of 
features 
and 
options 
based 
on 
an 


object-oriented 
architecture. 
In addition 
to being 


modular 
and configurable, 
functions 
beyond 
the 


nucleus 
include 
a sophisticated 
file management 


and 
I/O system, 
and 
powerful 
human 
interface. 


Both 
packages 
are 
easily 
customized 
and 
ex- 


tended 
by the user to match unique 
requirements. 


Device 
Function 
Number 
of 


Interrupts 


MULTIBUS interface 
Requests from MULTIBUS resident peripherals or other CPU 
8; may be expanded to 


boards 
64 with slave 8259A 
PICs on MULTIBUS 
boards 


8255A Programmable 
Signals input buffer full or output buffer empty; also BUS 
3 


Peripheral Interface 
INTR OUT general purpose interrupt from driver/terminator 
sockets 


8251A USART 
Transmit buffer empty and receive buffer full 
2 


8253Timers 
Timer 0, 1 outputs; function determined by timer mode 
2 


iSBX connectors 
Function determined by iSBX MULTIMODULE board 
4 


(2 per iSBX connector) 


Bus fail safe timer 
Indicates addressed MULTIBUSresident device has not reo 
1 


sponded to command within 6 msec 


Power fail interrupt 
Indicates AC power is not wit~in tolerance 
1 


Power line clock 
Source of 120 Hz signal from power supply 
1 


External interrupt 
General purpose interrupt from auxiliary (P2) connector on 
1 


backplane 


iSSC 337 MULTIMODULE 
Indicates error or exception condition 
1 


Numeric Data Processor 


intel" 


Word Size 


INSTRUCTION 
- 
8, 16,24, 
or 32 bits 


DATA - 
8, 16 bits 


System Clock 


5.00 MHz or 8.00 MHz ±0.1% 
(jumper 
selectable) 


Cycle Time 


BASIC 
INSTRUCTION 
CYCLE 


At 8 MHz - 
750 nsec 


- 
250 nsec (assumes 
instruction 
in the 


queue) 


At 5 MHz- 
1.2/4sec 


- 
400 nsec (assumes 
instruction 
in the 


queue) 
NOTES: 
Basic instruction 
cycle is defined as the fastest 
instruction 


time (i.e., two clock cycles). 


Memory Cycle Time 


RAM - 
500 nsec (no wait states) 


EPROM 
- 
Jumper 
selectable 
from 
500 nsec 
to 


875 nsec 


Memory Capacity/Addressing 


ON·BOARD 
EPROM 


Device 
Total Capacity 
Address 
Range 


2716 
8K bytes 
FEOOO-FFFFFH 


2732A 
16K bytes 
FCOOO-FFFFFH 


2764 
32K bytes 
F8000-FFFFFH 


27128 
64K bytes 
FOOOO-FFFFFH 


WITH 
iSBC 341 MUL TIMODULE 
EPROM 


Device 
Total Capacity 
Address 
Range 


2716 
16K bytes 
FCOOO-FFFFFH 


2732A 
32K bytes 
F8000-FFFFFH 


2764 
64K bytes 
FOOOO-FFFFFH 


27128 
128K bytes 
EOOOO-FFFFFH 


NOTES: 
iSBC 86/05 EPROM sockets support JEDEC 24/28·pin standard 
EPROMs and RAMs; iSBC 341 sockets also support E'PROMs. 


ON· BOARD 
RAM 
8K bytes 
- 
0-1 FFFH 


WITH 
iSBC 302 MUL TIMODULE 
RAM 


16K bytes - 
0-3FFFH 


I/O Capacity 


PARALLEL 
- 
24 programmable 
lines 
using 
one 


8255A. 


SERIAL 
- 
1 programmable 
line using 
one 8251A 


iSBX 
MUL TIMODULE 
- 
2 iSBX 
MUL T1MODULE 


boards 


Serial Communications 
Characteristics 


SYNCHRONOUS 
- 
5-8 bit characters; 
internal 
or 


external 
character 
synchronization; 
automatic 


sync insertion 


ASYNCHRONOUS 
- 
5-8 
bit 
characters; 
break 


character 
generation; 
1, 11/2, or 2 stop 
bits; 
false 


start bit detection 


BAUD RATES 


Frequency 
(kHz) 
Baud Rate (Hz) 
(Software 
Selectable) 
Synchronous 
Asynchronous 


+16 
+64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


NOTES: 
Frequency selected by I/O write of appropriate 16·bit frequency 
factor to baud rate register (8253 Timer 2). 


Timers 


INPUT 
FREQUENCIES 
Reference: 
2.46 MHz 
±0.1"1~ 
(0.041 /4sec period, 


nominal); 
or 153.60 kHz ± 0.1 % (6.51 /4sec period, 


nominal) 


NOTES: 
Above frequencies are user selectable, 


Event Rate: 
2.46 MHz max 


OUTPUT 
FREQUENCIES/TIMING 
INTERVALS 


Dual 


Single 
Timer/Counter 


Function 
Timer/Counter 
(Two Timers 


Cascaded) 


Min 
Max 
Min 
Max 


Real·time 
1.63 ~s 
427.1 ms 
3.·26s 
466.50 min 


Interrupt 


Programmable 
1.63 ~s 
427.1 ms 
3.26s 
466.50 min 


one·shot 


Rate generator 
2.342 Hz 613.5 kHz 0.000036 Hz 
306,8 kHz 


Square·wave 
2.342 Hz 613.5 kHz 
0.000036 Hz 
306.8 kHz 


rate generator 


Software 
1.63 ~s 
427.1 ms 
3.26s 
466.50 min 


triggered 
strobe 


Hardware 
1.63 ~s 
427.1 ms 
3.26s 
466.50 min 


triggered 
strobe 


Event 
- 
2.46 MHz 
- 
- 
counter 


Interfaces 


MUL T1BUS - 
All signals 
TTL compatible 


iSBX 
BUS - 
All signals 
TTL compatible 


PARALLEL 
110 - 
All signals 
TTL compatible 


SERIAL 
110 - 
RS232C 
compatible, 
configurable 


as a data set or data terminal 


TIMER 
- 
All signals 
TTL compatible 


INTERRUPT 
REQUESTS 
- 
All TTL compatible 


Connectors 


Double· 


Interface 
Sided 
Centers 
Mating 
Pins 
(in.) 
Connectors 


(qty) 


MULTIBUSTM 
86 
0.156 
Viking 


System 
3KH43/9AMK12 
Wire Wrap 


iSBX™ Bus 
8-Bit Data 
36 
0.1 
iSBX 960-5 


16-Bit Data 
44 
0.1 
iSBX 961-5 


Parallel I/O 
50 
0.1 
3M 3415-000 Flat 


(2) 
or 
TI H312125 Pins 


Serial I/O 
26 
0.1 
3M 3462-0001 
Flat 
or 


AMP 88106-1 Flat 


Line Drivers and Terminators 


I/O DRIVERS 
- 
The following 
line 
drivers 
are all 


compatible 
with 
the 110driver 
sockets 
on the iSBC 


86105 board 


Driver 
Characteristic 
Sink Current 
(mA) 


7438 
I,OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


NOTES: 
I = inverting; NI = non·inverting; OC = open collector. 


Port 1 of the 8255A 
has 20 mA totem-pole 
bidirec- 


tional 
drivers 
and 
1 kn terminators 


I/O TERMINATORS 
- 
220fl/330n 
divider 
or 1 


pullup 


2200/3300 (iSBC 901 OPTION) 
2200 


+5~ __ 
~",,----=L 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri·State 
50 


Address 
Tri·State 
50 


Commands 
Tri-State 
32 


Bus Control 
Open Collector 
20 


Physical Characteristics 


WIDTH 
- 
12.00 in. (30.48 em) 


HEIGHT 
- 
6.75 in. (17.15 em) 


DEPTH 
- 
0.70 in. (1.78 em) 


WEIGHT 
- 
14 oz (388 gm) 


Electrical Characteristics 


DC POWER 
REQUIREMENTS 


Current 
Requirements 


Configuration 
(All Voltages 
~ 5%) 


+5V 
+ 12V 
-12V 


Without 
EPROM' 
4.7A 
25 mA 
23 mA 


RAM only2 
120 mA 


With 8K EPROM' 
5.0A 
25 mA 
23mA 
(using 2716) 


With 16K EPROM3 
4.9A 
25 mA 
23 mA 


(using 
2732A) 
With 32K EPROM3 
4.9A 
25 mA 
23 mA 
(using 2764) 


NOTES: 
1. Does not 
include 
power for optional 
ROM/EPROM, I/O 
drivers, and I/O terminators. 
2. RAM chips powered via auxiliary power bus in power·down 


mode. 
3. Includes power required for 4 ROM/EPROM chips, and I/O 
terminators 
installed for 16 I/O lines; all terminator inputs 
low. 


Environmental 
Characteristics 


OPERATING 
TEMPERATURE 
- 
O·C to 55°C 


RELATIVE 
HUMIDITY 
- 
to 90% 
(without 
con'den- 


sation) 


Reference Manual 


143153·001 
- 
iSBC 
86/05 
Hardware 
Reference 


Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel 
sales 
rep- 


resentative, 
distributor 
office 
or from 
Intel 
litera- 


ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 


Clara, 
California 
95051. 


ORDERING INFORMATION 
Part Number 
Description 


SBC 86/05 
16-bit 
Single 
Board 
Computer 


with 
8K bytes 
RAM 


iSBC™ 80/30 (or pSBC 80/30*) 
SINGLE BOARD COMPUTER 


• 808SA CPU used as central processing 
unit 


• 16K bytes of dual port dynamic read/ 
write memory with on-board refresh 


• Sockets for up to 8K bytes of read only 
memory 


• Sockets for 8041A18741A Universal 
Peripheral Interface and interchange· 
able line drivers and line terminators 


• 24 programmable parallel 11/0 lines with 
sockets for interchangeable 
line drivers 
and terminators 


• Programmable synchronous/asynchro- 
nous RS232C compatible serial 
interface with fully software selectable 
baud rate generation 


• Full MULTIBUS®controllogic 
allowing 


up to 16 masters to share the system 


• 12 levels of programmable interrupt 
control 


• Two programmable 16·bit BCD or binary 


counters 


• Auxiliary power bus, memory protect, 


and power·fail interrupt control logic 
for RAM battery backup 


• Compatible with optional iSBC 80 CPU, 


memory, and I/O expansion boards 


The iSBC 80/30 Single Board Computer is a member of Intel's complete line of OEM computer systems which take full 
advantage of Intel's LSI technology to provide economical self·contained computer·based solutions for OEM applica' 
tions. The iSBC 80/30 is a complete computer system on a single 6.75x 12.00·inch printed circuit card. The CPU, 
system clock, read/write memory, nonvolatile read only memory, universal peripheral interface capability, I/O ports and 
drivers, serial communications interface, priority interrupt logic, programmable timers, MULTIBUS control logic, and 
bus expansion drivers all reside on the board. 


Intel's powerful 8·bit n·channel 8085A CPU, fabricated 
on a single LSI chip, is the central processor for the 
iSSC 80/30.The 8085A CPU is directly software compati· 
ble with the Intel 8080A CPU. The 8085A contains six 
8·bit general purpose registers and an accumulator. The 
six general purpose registers may be addressed individ· 
ually or in pairs, providing both single and double preci· 
sion 
operators. 
The minimum 
instruction 
execution 


time is 1.45 microseconds. The 8085A CPU has a 16·bit 
program counter. An external stack, located within any 
portion of iSSC 80/30 read/write memory, may be used 
as a last·in/first-out storage area for the contents of the 
program counter, flags, accumulator, and all of the six 
general purpose registers. A 16-bit stack pointer con· 
trois the addressing of this external stack. This stack 
provides subroutine nesting bounded only by memory 
size. 


Bus Structure 


The iSSC 80/30 has an internal bus for all on·board memo 
ory and 
110 operations 
and a system 
bus (I.e., the 


MULTISUS) for all external memory and 110 operations. 
Hence, local (on-board) operations do not tie up the sys· 
tem bus, and allow true parallel processing when sev· 
eral bus masters (I.e., DMA devices, other single board 
computers) are used in a multi master scheme. A block 
diagram of the iSSC 80/30 functional 
components 
is 


shown in Figure 1. 


RAM Capacity 


The 
iSSC 
80/30 
contains 
16K 
bytes 
of 
dynamic 
read/write memory using Intel 2117 RAMs. All RAM read 
and write operations are performed at maximum proc· 
essor speed. Power for the on-board RAM may be pro· 
vided on an auxiliary power bUs, and memory protect 
logic is included for RAM battery backup requirements. 
The iSSC 80/30 contains a dual port controller, 
which 


provides dual port capability for the on-board RAM memo 
ory. RAM accesses may occur from either the iSSC 
80/30 or from any other bus master interfaced via the 


US,ER 
DESIGNATED 


PERIPHERALS 
.U PROGRAMMABLE 
PA.RAlLEl 
UO LINES 


TWO 


PROGRAM· 


MABLE 
TIMERS 


MULTIBUS. Since 
on-board 
RAM accesses 
do 
not 
require the MULTIBUS,the bus is available for any other 
concurrent operations (e.g., DMA data transfers) requir- 
ing the use of the MULTIBUS. Dynamic RAM refresh is 
accomplished 
automatically 
by the 
iSBC 80130 for 
accesses originating 
from either the CPU or via the 
MULTIBUS_Memory space assignment can be selected 
independently 
for 
on-board 
and 
MULTIBUS 
RAM 
accesses. The on-board RAM, as seen by the 8085A 
CPU, 
may 
be 
placed 
anywhere 
within 
the 
0- 
to 
64K-address space. The iSBC 80/30 provides extended 
addressing jumpers to allow the on-board RAM to reside 
within a one megabyte address space when accessed 
via the MULTIBUS. In addition, jumper options are pro- 
vided which allow the user to reserve 8K- and 16K-byte 
segments of on-board RAM for use by the 8085A CPU 
only. This reserved RAM space is not accessible via the 
MULTIBUS and does not occupy any system address 
space. 


EPROM/ROM 
Capacity 


Sockets for up to 8K bytes of nonvolatile read only 
memory are provided on the iSBC 80/30board. Readonly 
memory may be added in 1K-byte increments up to a 
maximum of 2K bytes using Intel 2708 or 2758 erasable 
and electrically 
reprogrammable ROMs (EPROMs); in 
2K-byte increments up to a maximum of 4K bytes using 
Intel 2716 EPROMs; or in 4K-byte increments up to 8K 
bytes maximum using Intel 2732 EPROMs.All on-board 
EPROM/ROM operations 
are performed at maximum 
processor speed. 


Parallel 
I/O Interface 


The iSBC 80/30 contains 24 programmable parallel I/O 
lines implemented using the Intel 8255A Programmable 
Peripheral Interface. The system software is used to 
configure the I/O lines in any combination of unidirec- 
tional input/output and bidirectional 
ports indicated in 
Table 1. Therefore, the I/O interface may be customized 
to meet specific 
peripheral requirements. In order to 
take full advantage of the large number of possible I/O 
configurations, 
sockets are provided for interchange- 
able I/O line drivers and terminators. Hence, the flexibil- 


ity of the I/O interface is further enhanced by the capabi- 
lity of selecting the appropriate combination of optional 
line drivers and terminators to provide the required sink 
current, polarity, and drive/termination 
characteristics 


for each application. The 24 programmable I/O lines and 
signal ground lines are brought out to a 50-pin edge con- 
nector that mates with flat, woven, or round cable. 


Universal 
Peripheral 
Interface 
(UPI) 


The iSBC 80/30 provides sockets for a user supplied In- 
tel 8041A/8741A Universal Peripheral Interface (UPI)chip 
and the associated line drivers and terminators for the 
UPI's I/O ports. The 8041A18741A is a single 
chip 


microcomputer 
containing 
a CPU, 1K bytes of ROM 


(8041A) or EPROM(8741A),64 bytes of RAM, 18program- 
mable I/O lines, and an 8-bit timer. Special interface 
registers included in the chip allow the 8041A to func- 
tion as a slave processor to the iSBC 80/30's 8085A CPU. 
The UPI allows the user to specify algorithms for con- 
trollin9 
user peripherals directly 
in the chip, thereby 


relieving the 8085A for other system functions. 
The 


iSBC 80/30 provides an RS232C driver and an RS232C 
receiver for optional connection to the 8041A18741Ain 
applications 
where the UPI is programmed to handle 


simple serial interfaces. For additional information, in- 
cluding 8041A18741Ainstructions, 
refer to the UPI-41A 


User's Manual and application note AP-41. 


A programmable communications 
interface using the 


Intel 8251A Universal Synchronous/Asynchronous 
Re- 


ceiver/Transmitter 
(USART) is contained on the iSBC 


80/30. A software selectable baud rate generator pro- 
vides the USART with all common communication 
fre- 


quencies. The USART can be programmed by the sys- 
tem software to select the desired asynchronous 
or 


synchronous 
serial data transmission 
technique 
(in- 


cluding IBM By-Sync). The mode of operation (I.e., syn- 
chronous 
or 
asynchronous), 
data 
format, 
control 


character format, parity, and baud rate are all under pro- 
gram control. The 8251A provides full duplex, double 
buffered transmit and receive capability. Parity, overrun, 
and framing error detection are all incorporated in the 


Mode of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched & 
Latched 
Latched & 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
Xl 


4 
X 
X 
X' 


Note 
1. Part of port 3 must be used as a control 
p~rt when either port 1 or port 2 are used as a latched and strobed 
input or a latched 
and strobed output 
port 


or port 1 is used as a bidirectional 
port. 


and 
asynchronous 
and 
synchronous 
modems. 
The 
RS232C command lines, serial data lines, and signal 
ground line are brought out to a 26·pin edge connector 
that mates with RS232Ccompatible flat or round cable. 


Multimaster 
Capability 


The iSBC 80/30 is a full computer on a single board with 
resources capable of supporting a great variety of OEM 
system requirements. For those applications requiring 
additional 
processing 
capacity 
and the benefits 
of 
multiprocessing 
(i.e., several CPUs and/or controllers 


logically sharing system tasks through communication 
over the system bus), the iSBC 80/30 provides full 
MULTIBUS arbitration control logic. This control logic 
allows up to three iSBC 80/30's or other bus masters to 
share the system bus in serial (daisy chain) priority fash· 
ion, and up to 16 masters to share the MULTIBVS with 
the addition of an external priority network. The MULTI- 
BUS arbitration 
logic operates synchronously 
with a 


MULTIBUS clock (provided by the iSBC 80/30 or option· 
ally connected directly to the MULTISUS clock) while 
data is transferred via a handshake between the master 
and slave modules. This allows different 
speed can· 


trollers to share resources on the same bus, and trans- 
fers via the bus proceed asynchronously. Thus, transfer 
speed is 
dependent 
on transmitting 
and receiving 


devices only. This design prevents slow master modules 
from being handicapped in their attempts to gain can· 
trol of the bus, but does not restrict the speed at which 
faster modules can transfer data via the same bus. The 
most obvious applications for the master·slave capabili· 
ties of the bus are multiprocessor configurations, high 
speed direct memory access (DMA)operations, and high 
speed peripheral control, but are by no means limited to 
these three. 


Programmable 
Timers 


The iSSC 80/30 provides three independent, fUlly pro· 
grammable 16-bit interval timers/event counters utiliz· 
ing the Intel 8253 Programmable Interval Timer. Each 
counter is capable of operating in either BCD or binary 
modes. Two of these timers/counters are available to 
the systems designer to generate accurate time inter· 
vals under software control. Routing for the outputs and 
gate/trigger inputs of two of these counters is jumper 
selectable. The outputs may be independently routed to 
the 8259A Programmable Interrupt Controller, to the I/O 
line drivers associated with the 8255A Programmable 
Peripheral Interface, and to the 8041A/8741AUniversal 
Programmable Interface, or may be routed as inputs to 
the. 8255A and 8041A/8741A chips. The gate/trigger in· 
puts may be routed to I/O terminators associated with 
the 8255A or as output connections from the 8255A.The 
third interval timer in the 8253 provides the program· 
mabie baud rate generator for the iSBC 80/30 RS232C 
USART serial port. In utilizing 
the iSSC 80/30, the 


systems designer Simply configures, via software, each 
timer 
independently 
to 
meet system 
requirements. 


are available, as shown in Table 2. The contents of each 
counter may be read at any time during system opera· 
tion with simple read operations for event counting ap· 
plications, and special commands are included so that 
the contents of each counter can be read "on the fly". 


Function 


Interrupt on 
terminal count 


Programmable 
one·shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When terminal count is reached, an 
interrupt request is generated. This 
function is extremely useful for gen· 
eration of real·time clocks. 


Output goes low upon receipt of an 
external 
trigger 
edge or software 


command and returns high when ter· 
minal count is reached. This func· 
tion is retriggerable. 


Divide by N counter. The output will 
go low for one input clock cycle, and 
the period from one low·going pulse 
to the next is N times the input clock 
period. 


Output will remain high until one· 
half the count has been completed, 
and go low for the other half of the 
count. 


Output remains high until software 
loads count (N).N counts after count 
is loaded, output goes iow for one in· 
put clock period. 


Output 
goes 
low 
for 
one 
clock 


period N counts after rising edge on 
counter trigger input. The counter is 
retriggerable. 


On a jumper selectable basis, the 
clock input becomes an input from 
the external system. CPU may read 
the number of events occurring after 
the counting 
"window" 
has been 


enabled or an interrupt may be gen- 
erated after N events occur in the 
system. 


Interrupt 
Capability 


The iSBC 80/30 provides vectoring 
for 
12 interrupt 


levels. Four of these levels are handled directly by the 
interrupt processing capability of the 8085A CPU and 
represent the four highest priority interrupts of the iSSC 
80/30.Requests are routed to the 8085A interrupt inputs, 
TRAP, RST7.5,RST6.5,and RST5.5(in decreasing order 
of priority) and each input generates a unique memory 
address (TRAP: 24H; RST 7.5: 3CH; RST 6.5: 34H; and 
RST 5.5: 2CH). An 8085A jump instruction 
at each of 


these addresses then provides linkage to interrupt ser· 


vice routines located independently anywhere in mem- 
ory. All interrupt inputs with the exception of the trap 
interrupt may be masked via software. The trap interrupt 
should be used for conditions 
such as power·down 


sequences which require immediate attention 
by the 


8085A CPU. The Intel 8259A Programmable Interrupt 
Controller (PIC) provides vectoring for the, next eight 
interrupt levels. As shown in Table 3, a selection of four 
priority processing modes is available to the systems 
designer for use in designing request processing con- 
figurations 
to match system requirements. Operating 


mode and priority 
assignments 
may be reconfigured 


dynamically 
via software at any time during system 


operation. The PIC accepts interrupt requests from the 
programmable parallel and serial I/O interfaces, the pro· 
grammable timers, the system bus, or directly 
from 


peripheral equipment. The PIC then determines which 
of the incoming requests is of the highest priority, deter- 
mines whether this request is of higher priority than the 
level currently being serviced, and, if appropriate, issues 
an interrupt to the CPU. Any combination of interrupt 
levels may be masked, via software, by storing a single 
byte in the interrupt mask register of the PIC. The PIC 
generate~ a unique memory address for each interrupt 
level. These addresses are equally spaced at intervals of 
4 or 8 (software selectable) bytes. This 32- or 64-byte 
block may be located to begin at any 32- or 64-byte 
boundary in the 65,536-byte memory space. A single 
8085A jump instruction at each of these addresses then 
provides linkage to locate each interrupt service routine 
independently anywhere in memory. 


Mode 
Operati'on 


Fully 
Interrupt request line priorities fixed at 0 


nested 
as highest, 7 as lowest. 


Auto- 
Equal priority. Each level, after receiving 


rotating 
service, becomes the lowest priority level 
until next interrupt occurs. 


Specific 
System software assigns lowest priority 


priority 
level. Priority of all other levels based in 
sequence numerically on this assignment. 


Polled 
System 
software 
examines 
priority- 


encoded system interrupt status via inter- 
rupt status register. 


Interrupt Request Generation - 
Interrupt requests may 


originate from 18 sources. Two jumper selectable inter· 
rupt requests can be automatically 
generated by the 


programmable peripheral interface when a byte of infor- 
mation is ready to be transferred to the CPU (I.e., input 
buffer is full) or a byte of information has been trans· 
ferred to a peripheral 
device (I.e., output 
buffer 
is 


empty). Two jumper selectable interrupt requests can be 
automatically generated by the USARTwhen a character 
is ready to be transferred to the CPU (I.e., receive chan- 
nel buffer is full), or a character is ready to be trans- 
mitted (I.e., transmit channel data buffer is empty). A 
jumper selectable request can be generated by each of 
the programmable timers and by the universal periph- 
eral interface, eight additional 
interrupt request lines 


are available to the user for direct 
interface to user 


designated peripheral devices via the system bus, and 
two 
interrupt 
request 
lines 
may be jumper 
routed 


directly from peripherals via the parallel I/O driver/termi- 
nator section. 


Power-Fail 
Control 


Control logic is also included to accept a power·fail 
interrupt in conjunction with the AC-Iow signal from the 
iSSC 635 Power Supply or equivalent. 


Expansion 
Capabilities 


Memory and I/O capacity may be expanded and addi· 
tional functions added by using Intel MULTISUS com- 
patible 
expansion 
boards. 
High speed integer 
and 


floating point arithmetic capabilities may be added by 
using the iSSC 310A High Speed Mathematics 
Unit. 


Memory may be expanded to 65,536bytes by adding user 
specified combinations of RAM boards, EPROMboards, 
or combination boards. Input/output capacity may be in· 
creased by adding digital I/O and analog I/O expansion 
boards. Mass storage capability may be achieved by add- 
ing single or double density diskette controllers as sub- 
systems. 
Modular expandable backplanes 
and card· 


cages are available to support multi-board systems. 


Real-Time Software 


Intel's iRMX 80 Real-Time Multi·Tasking Executive soft· 
ware, specifically 
designed 
for Intel iSSC 80 single 


board computers, provides the capability to monitor and 
control 
multiple 
asynchronous 
external 
events. The 


iRMX 80 executive, which synchronizes and controls the 
execution of multiple tasks, is provided as a linkable and 
relocatable module requiring only 2K bytes of memory 
space. Optional linkable and relocatable modules for 
teletypewriter 
and CRT control, diskette 
file system, 


high speed math unit, and analog subsystems are also 
available. 


System 
Development 
Capability 


The developmentcycle of iSSC 80/30-basedproducts may 
be significantly reduced using Intel's system development 
tools available today. For those not requiring hardware 
emulation 
capability, 
Intel provides 
a new low cost 


microcomputer development system. The iPDS, Personal 
Development System, provides low cost system develop- 
ment for the iSSC 80/30 board, while at the same time pro- 
viding personalcomputercapability for the engineer.TheIn- 
tellec Series II family of compatible microcomputerdevelop- 
ment systems providesa rangeof capability from a low cost 
disk-based edit debug workstation to a high performance, 
fully compatible hard-disk-based software development 
system. A unique in-circuit emulator (ICE-85A)option pro- 
vides the capability of developing and debugging software 
directly on the iSSC 80/30 board. 


Programming 
Capability 


PLfM·80 - 
Intel's 
high level programming 
language, 


PUM, is also available as a resident Intellec microcom- 
puter development system option. PUM provides the 
capability to program in a natural, algorithmic language 
and eliminates the need to manage register usage or 


allocate memory. PUM programs can be written in a 
much shorter time than assembly language programs 
for a given application. 


FORTRAN-80 - 
For applications 
requIring computa- 
tional 
and formatted 
I/O capabilities, 
the high level 


FORTRAN-80 programming language is also available 
as a resident 
option 
of the 
intellec 
system. 
FOR- 
TRAN-80 meets and exceeds the ANS FORTRAN 77 
subset language specification. The FORTRAN-80 com- 
piler produces relocatable 
object code that may be 
easily linked with other FORTRAN-80,PUM, or assem- 
bly language program modules. This gives the user wide 
flexibility 
in developing software by using the best soft- 
ware tool for a particular functional module within the 
user's application. 


BASIC-80 - 
A high level language interpreter with ex- 


tended disk capabilities which operates under the iRMX 
80 Real-Time Multi-tasking 
Executive and translates 


BASIC-80source programs into an internally executable 
form. This language interpreter, provided as a set of 
linkable object modules, is ideally suited to the OEM 
who requires a pass thru programming language. The 
BASIC-80 programs may be created, stored and inter- 
preted on the iSBC 80-based system. The BASIC-80 
language has a rich complement of statements, func- 
tions, and commands to program applications requiring 
a full range of 1)string manipulation and disk I/Ofor data 
processing, 2)single and double precision floating point 
and array handling for numeric analysis, or 3) port I/O 
with 
mask operations 
controlled 
through 
bit-wise 


Boolean logical operators. 


Word Size 
Instruction - 
8, 16, or 24 bits 


Data - 
8 bits 


Cycle Time 
Basic Instruction Cycle - 
1.45I-'s 


Note 
Basic 
instruction 
cycle 
is defined 
as the fastest 
instruction 
(Le., four 


clock cycles). 


Memory Addressing 


On-Board ROM/EPROM - 
0-07FF (using 2708 or 2758 


EPROMs);O-OFFF(using 2716 EPROMs);0-1FFF (using 
2716 EPROMs;0-1FFF (using 2732 EPROMs). 
On-Board RAM - 
16K bytes of dual port RAM starting 


on a 16K boundary. One or two 8K-byte segments may 
be reserved for CPU use only. 


Memory Capacity 
On-Board Read Only Memory - 
8K bytes (sockets only) 
On-Board RAM - 
16K bytes 
Off-Board Expansion - 
Up to 65,536 bytes in user 


specified combinations of RAM, ROM, and EPROM 


110Addressing 
On-Board Programmable I/O (see Table 1) 


Control 


EO 


1/0 Capacity 


Parallel - 
42 programmable lines using one 8255A (24 


I/O lines) and an optional 8041A/8741A(18 I/O lines) 
Serial - 
2 programmable lines using one 8251A and an 


optional 8041AJ8741Aprogrammed for serial operation 


Note: 


For additional 
information 
on the 8041A18741A refer to the UPI-41 User's 
Manual 
(Publication 
9800504). 


Serial Communications 
Characteristics 


Synchronous - 
5-8 
bit characters; internal or external 
character synchronization; automatic sync insertion. 
Asynchronous - 
5-8 
bit characters; break character 


generation; 1, 1V2, or 2 stop bits; false start bit detec- 
tion. 


Baud Rates 


Frequoncy 
(k Hz) 
Saud Rate (Hz) 


(Softwaro 
Solectable) 
Synchronous 
Asynchronous 


+ 
16 
+ 64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


Not8 


Frequency 
selected 
by 110 write of appropriate 
16-bit frequency 
factor to 


baud rate register 
(8253 Timer 2). 


Interrupts 


Addresses for 8259A Registers (Hex notation, I/O ad- 
dress space) 


DA 
Interrupt request register 


DA 
In-service register 


DB 
Mask register 


DA 
Command register 


DB 
Block address register 


DA 
Status (polling register) 


Note 
Several registers 
have the same physical 
address; 
sequence 
of access 


and one data bit of control 
word determine 
which register 
will respond. 


Interrupt Levels routed to 8085A CPU automatically vec- 
tor the processor to unique memory locations: 


Interrupt 
Memory 
Priority 
Type 
Input 
Address 


TRAP 
24 
Highest 
Non·maskable 


RST 7.5 
3C 
t 
Maskable 


RST 6.5 
34 
Maskable 


RST 5.5 
2C 
Lowest 
Maskable 


Timers 


Register Addresses (Hex notation, I/O address space) 


DF 
Control register 


DC 
Timer 0 


DD 
Timer 1 
DE 
Timer 2 


Note 
Timer 
counts 
loaded 
as two 
sequential 
output 
operations 
to same 
address, 
as given. 


Input Frequencies 
Reference: 2.46 MHz ±0.1% (0.041f's period, nominal); 
1.23 MHz±0.1%(0.81 f's period, nominal); or 153.60kHz 
± 0.1%(6.51 f's period nominal). 


Note 
Above 
frequencies 
are user selectable 


Single 
Timer/Counter 
Dual Timer/Counter 


Functlon 
(Two Timers 
Clsclded) 


Mln 
MIX 
Mln 
MI' 


Real-time 
1.63 "s 
427.1 ms 
3.26 "s 
466.50 min 


interrupt 
I 
Programmable 
1.63 "s 
427.1 ms 
3.26 "s 
466.50 min 
I 


one-shot 


Rate generator 
2.342 Hz 
613.5 kHz 
0.000036 
Hz 
306.8 kHz 


Square-wave 
2.342 Hz 
613.5 kHz 
0.ססOO36 Hz 
306.8 kHz 
rate generator 


Software 
1.63 "s 
427.1 ms 
3.26 "s 
466.50 
min 
triggered 
strobe 


Hardware 
1.63 "s 
427.1 
ms 
3.26 "s 
466.50 
min 
triggered 


I 
strobe 


Interfaces 
MULTIBUS - 
All signals TIL compatible 


Parallel 110 - 
All signals TIL compatible 


Interrupt Requests - 
All TIL compatible 


Timer - 
All signals TIL compatible 


Serial I/O - 
RS232Ccompatible, data set configuration 


System Clock (808SA CPU) 
2.76 MHz ±0.1% 


Auxiliary 
Power 


An aUXiliary power bus is provided to allow separate 
power to RAM for systems requiring battery backup of 
read/write memory. Selection of this 
auxiliary 
RAM 


power bus is made via jumpers on the board. 


Intertlce 
Pin. 
Cente •• 
Mltlng 
Connectors 
(qty) 
(In.) 


Bus 
B6 
0.156 
Viking 
2KH4319AMK12 


Pa,"lIelllO 
50 
0.1 
3M 3415-000 


Se,'.'IIO 
26 
0.1 
3M 3462'()()() 


Memory Protect 
An active·low TIL compatible memory protect signal is 
brought out on the auxiliary connector Which, when 
asserted, disables read/write access to RAM memory on 
the board. This input is provided for the protection of 
RAM contents during system power·down sequences. 


Line Drivers and Terminators 


110 Drivers- 
The following iine drivers are all compatl' 


ble with the I/O driver sockets on the iSSC 80/30. 


Driver 
Characteristic 
Sink Current (mA) 


7438 
LOC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
LOC 
16 
7409 
NLOC 
16 


7408 
NI 
16 


7403 
LOe 
16 


7400 
I 
16 


no\<' 


+5V 
----~--~--~---~ 


330Q 
• 


220Qf330Qr---------'\I'v\r.------- 
iSBC 901 OPTION 


Function 


Data 


Address 


Chlrlcloristic =1 


Tri·state 


Tri-state 


Tri-state 


Sink Current (mA) 


50 
50 


32 


Physical Characteristics 
Width - 
12.00in. (3048 cm) 


Height - 
6.75 in. (17.15cm) 


Depth - 
0.50 in. (1.27cm) 
Weight - 
18 oz. (509.6gm) 


Current Requirements 


Conllgu· 
VCC= 
+SV 
VOO= 
+12V 
V88= 
-SV 
VAA= 
-12V 


retlon 
:l:S%(mu) 
:l:S%(mu) 
:l:S%(mu) 
:l:S%(mu) 


Without 
ICC=3.SA 
100=220 
mA 
18B=- 
IM=SOmA 
EPROM1 


With 
3.6A 
220 mA 
- 
SOmA 
80411874,2 


RAM only3 
350 mA 
20 mA 
2.5 mA 
- 


With 
3.5A 
320 mA 
- 
ISO mA 
iSBC 5304 


With 2K 
EPROM5 
4.4A 
350 mA 
95 mA 
40 mA 


(using 8708) 


With 2K 
EPROM5 
4.6A 
220 mA 
- 
SOmA 


(using 
2758) 


With4K 
EPROM5 
4.6A 
220 mA 
- 
SO mA 


(using 
2716) 


With 8K 
EPROM5 
4.6A 
220 mA 
- 
SO mA 


(using 
2332) 


Notes 


1. Does 
not 
include 
power 
required 
for optional 
EPROMIROM, 
8041A1 


8741A 
110 drivers, 
and 
1/0 terminators. 


2. Does not include 
power 
required 
for optional 
EPROMIAOM, 
110drivers 
and 1/0 terminators. 


3: RAM chips 
powered 
via auxiliary 
power bus 


4. Does 
not 
include 
power 
required 
for optional 
EPROMIROM, 
8041A1 
8741A 
1/0 drivers, 
and liD terminators. 
Power 
for iSSC 530 is supplied 


through 
the serial 
port connec1or. 


5. Includes 
power 
required 
for 
two 
EPROM/ROM 
chips, 
8041A1874'A 


and 220013300 input 
terminators 
installed 
for 34 1/0 lines; 
all terminator 
inputs low. 


Reference Manual 


98006118 - 
iSBC 80/30 Single Board Computer 
Hard- 


ware Reference Manual (NOT SUPPLIED) 


Reference manuals are shipped with each product only 
if designated 
SUPPLIED (see above). Manuals 
may be 


ordered from any Intel sales representative, 
distributor 


office or from Intel Literature 
Department, 
3065 Bowers 


Avenue, Santa Clara, California 
95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SBC 80/30 
Single Board Computer 
with 16K bytes RAM 


iSBC™ 80/24 (or pSBC 80/24 *) 
SINGLE 
BOARD COMPUTER 


• Upward compatible 
with iSBC 80/20·4 
Single 
Board Computer 


• 8085A·2 CPU operating 
at 4.8 or 2.4 MHz 


• Two iSBX™ bus connectors 
for iSBX 
MULTIMODULE™ 
board expansion 


• 4K bytes of static 
read/write 
memory 
expandable 
on· board to 8K bytes using 
the iSBC 301 MUL TIMODULE 
Board 


• Sockets 
for up to 32K bytes of read only 
memory 


• 48 programmable 
parallel 
I/O lines with 
sockets 
for interchangeable 
line drivers 
and terminators 


• Programmable 
synchronous/asynchro· 


nous RS232C compatible 
serial 
interface 
with software 
selectable 
baud rates 


• Full MULTIBUS® control 
logic for 
multi master configurations 
and 
system expansion 


• Two programmable 
16·bit BCD or binary 


timers/event 
counters 


• 12 levels of programmable 
interrupt 
control 


• Auxiliary 
power bus, memory 
protect, 


and power· fail interrupt 
control 
logic 


provided 
for battery 
backup 
RAM 
requirements 


The Intel® iSBC 80/24 Single Board Computer 
is a member of Intel's complete 
line of OEM microcomputer 
systems 
which 
take full advantage 
of Intel's 
LSI technology 
to provide economical, 
self-contained 
com- 
puter-based 
solutions 
for OEM applications. 
The iSBC 80/24 board is a complete 
computer 
system 
on a 
single 
6.75 x 12.00-inch 
printed 
circuit 
card. 
The CPU, system 
clock, 
iSBX bus 
interface, 
read/write 
memory, read only memory sockets, 
110 ports and drivers, serial communications 
interface, 
priority 
inter- 


rupt logic, and programmable 
timers all reside on the board. Full MUL TIBUS interface 
logic is included 
to 


offer compatibility 
with the Intel OEM Microcomputer 
Systems 
family of Single Board Computers, 
expan- 
sion memory options, 
digital 
and analog 
110 expansion 
boards, and peripheral 
and communications 
con- 


trollers. 


The following 
are trademarks 
of Intel 
Corporation 
and may be used only 
to describe 
Intel 
products: 
Index, 
Intel, 
'nsite, 
Intallee, 
Library 
Manager, 
Megachassis, 
Micromap. 


MULTIBUS, 
PROMPT, 
iRMX, 
UPI, ,.Scope, 
Promware, 
MeS, 
ICE, iSBC, 
iSBX, 
MULTIMODULE 
and ieS. Intel 
Corporation 
assumes 
no responsibility 
lor the use of any circuitry 


other 
than Circuitry 
embodied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are implied. 


© INTEL 
CORPORATION, 
1980, 1981 


inter 


FUNCTIONAL 
DESCRIPTION 
Central 
Processing 
Unit 


Intel's 
powerful 
8-bit N-channel 
8085A-2 CPU fabri- 


cated on a single 
LSI chip, is the central 
processor 


for the iSBC 80/24 board operating 
at either 
4.8 or 


2.4 MHz (jumper 
selectable). 
The 8085A-2 CPU is 


directly 
software 
compatible 
with 
the Intel 8080A 


CPU. The 8085A-2 contains 
six 8-bit general 
pur- 


pose 
registers 
and an accumulator. 
The six gen- 
eral purpose 
registers 
may be addressed 
individu· 


ally 
or in pairs, 
providing 
single 
and double 
pre- 
cision 
operators. 
Minimum 
instruction 
execution 


time 
is 826 nanoseconds. 
A block 
diagram 
of the 


iSBC 
80/24 
functional 
components 
is shown 
in 
Figure 
1. 


MULTIMODULE 
Board Expansion 


The new iSBX bus interface 
brings 
an entirely 
new 


dimension 
to system 
design 
offering 
incremental 


on·board 
expansion 
at minimal 
cost. 
Two 
iSBX 


bus 
MUL TIMODULE 
connectors 
are provided 
for 


plug-in 
expansion 
of 
any 
iSBX 
MULTIMODULE 


board. The iSBX MULTIMODULE 
concept 
provides 


the ability 
to adapt quickly 
to new technology, 
the 


economy 
of buying 
only what 
is needed, 
and the 


ready 
availability 
of a spectrum 
of functions 
for 


greater 
application 
potential. 
iSBX 
boards 
are 


available 
to provide 
expansion 
equivalent 
to the 


I/O available 
on the iSBC 80/24 board or the user 


may configure 
entirely 
new functionality, 
such as 
math, directly 
on board. The iSBX 350 Parallel 
110 


MULTI MODULE 
board provides 
24 I/O lines 
using 


an 
8255A 
Programmable 
Peripheral 
Interface. 


Therefore, 
two 
iSBX 350 modules 
together 
with 
the 
iSBC 80/24 board 
may offer 
96 lines 
of pro· 


grammable 
I/O. Alternately, 
a serial 
port 
may be 


added 
using 
the iSBX 351 Serial 
110 MULTIMOD· 


ULE board and math may be configured 
on-board 
with the iSBX 332 Floating 
Point Math or iSBX 331 


Fixed/Floating 
Point 
Math MUL TIMODULE 
board. 


Future 
iSBX products 
are also planned. 
The iSBX 


MULTI MODULE board is a logical 
extension 
of the 
on·board 
programmable 
110 and 
is accessed 
by 


the iSBC 80/24 single 
board computer 
as common 
110 
port 
locations. 
The 
iSBX 
board 
is 
coupled 


directly 
to 
the 
8085A·2 
CPU 
and 
therefore 
be· 


comes 
an 
integral 
element 
of 
the 
iSBC 
80/24 


single 
board 
computer 
providing 
optimum 
performance. 
In addition, 
RAM memory 
capacity 


may be expanded 
to 8K bytes using 
the iSBC 301 


4K Byte 
RAM 
MULTIMODULE 
board. 
All 
MULTI- 


MODULE 
boards 
ranging 
from 
the 
iSBC 
301 


module 
to 
the 
iSBX 
modules 
offer 
incremental 


expansion, 
optimum 
performance, 
and 
minimal 
cost. 


.. 
PROGRAMMABLE 


PARALLEL 
110 LINES 


Figure 
1. iSBC 80/24 Single 
Board Computer 
Block 
Diagram 


3-106 


inter 


Memory Addressing 


The 8085A-2 has a 16-bit program counter which 
allows direct addressing of up to 64K bytes of 
memory. An external stack, located within any 
portion of read/write memory, may be used as a 
last-in/first-out storage area for the contents of 
the program counter, flags, accumulator, and all 
of the six general purpose registers. A 16-bitstack 
pointer controls the addressing of this external 
stack. This stack provides subroutine 
nesting 


bounded only by memory size. 


Memory Capacity 


The iSBC 80/24 board contains 4K bytes of static 
read/write memory using Intel 8185-2 RAMs. In 
addition, the on-board RAM capacity may be ex- 
panded to 8K bytes with the iSBC 301 4K byte 
RAM MULTIMODULE board. All RAM read and 
write operations are performed at maximum proc- 
essor speed. Power for the on-board RAM may be 
provided on an auxiliary power bus, and memory 
protect logic is included for RAM battery backup 
requirements. 


Four sockets are provided for up to 32K bytes of 
nonvolatile read only memory on the iSBC 80/24 
board. EPROM may be added in 1K byte incre- 
ments up to 4K bytes (using Intel 2708or 2758);in 
2K byte increments up to 8K bytes (using Intel 
2716); in 4K byte increments up to 16K bytes 
(using Intel 2732);or in 8K byte increments up to 
32K bytes (using Intel 2764). 


Parallel 1/0 Interface 


The iSBC 80/24 board contains 48 programmable 
parallel I/O lines implemented using two Intel 
8255A Programmable Peripheral Interfaces. The 
system software is used to configure the I/O lines 
in any combination of unidirectional input/output 
and bidirectional ports as indicated in Table 1. 
Therefore, the I/O interface may be customized to 
meet specific peripheral requirements. In order to 
take full advantage of the large number of possi- 
ble I/O configurations, sockets are provided for in- 
terchangeable I/O line drivers and terminators. 
Hence, the flexibility of the I/O interface is further 
enhanced by the capability of selecting the appro- 
priate combination of optional line drivers and ter- 
minators to provide the required sink current, 
polarity, and drive/termination characteristics for 
each application. The 48 programmable I/O lines 
and signal ground lines are brought out to two 
50-pinedge connectors that mate with flat, woven, 
or round cables. 


A programmable communications interface using 
the Intel 8251A Universal Synchronous/Asynchro- 
nous ReceiverlTransmitter (USARn is contained 
on the iSBC 80/24 board. A software selectable 
baud rate generator provides the USARTwith all 
common communication frequencies. The USART 
can be programmed by the system software to 
select the desired asynchronous or synchronous 
serial data transmission technique (including IBM 


Mode.of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched & 
Latched 
Latched & 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X' 


4 
X 
X 
X' 


4 
8 
X 
X 
X 
X 
X 


5 
8 
X 
X 
X 
X 


6 
4 
X 
X 
X2 


4 
X 
X 
X2 


NOTES: 
1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed input or a latched and 


strobed output port or port 1 is used as a bidirectional 
port. 


2. Part of port 6 must be used as a control port when either port 4 or port 5 are used as a latched and strobed input or a latched and 
strobed output port or port 4 is used as a bidirectional 
port. 


Bi-Sync). The mode of operation 
(i.e. synchronous 
or asynchronous), 
data format, 
control 
character 


format, 
parity, and baud rate are all under program 
control. 
The 8251A 
provides 
full 
duplex, 
double 
buffered 
transmit 
and 
receive 
capability. 
Parity, 
overrun, 
and framing 
error detection 
are all incor- 
porated 
in the USART. The RS232C compatible 
in- 


terface, 
in conjunction 
with the USART, provides a 
direct 
interface 
to RS232C compatible 
terminals, 
cassettes, 
and 
asynchronous 
and 
synchronous 
modems. 
The RS232C command 
lines, serial data 


lines, and signal 
ground 
line are brought 
out to a 
26-pin 
edge 
connector 
that 
mates 
with 
RS232C 
compatible 
flat or round cable. 


Multimaster 
Capability 


The 
iSBC 
80/24 board 
is a full 
computer 
on a 
single 
board with resources 
capable of supporting 
a large variety 
of OEM system 
requirements. 
For 
those 
applications 
requiring 
additional 
process- 


ing capacity 
and the benefits 
of multiprocessing 


(i.e. several CPUs and/or controllers 
logically 
shar- 
ing system 
tasks through 
communication 
over the 


system 
bus), the 
iSBC 80/24 board 
provides 
full 
MUL TIBUS arbitration 
control 
logic. 
This control 


logic allows 
up to three iSBC 80/24 boards or other 
bus 
masters 
to share 
the 
system 
bus 
in serial 


(daisy chain) priority 
fashion, 
and up to 16 masters 


to share the MUL TIBUS system 
bus with the addi- 
tion 
of an external 
priority 
network. 
The MULTI- 
BUS 
arbitration 
logic 
operates 
synchronously 


with 
a MULTIBUS 
clock 
(provided 
by the 
iSBC 


80/24 board or optionally 
connected 
directly 
to the 


MULTIBUS 
clock) 
while 
data is transferred 
via a 
handshake 
between 
the master 
and slave modu- 


les. 
This 
allows 
different 
speed 
controllers 
to 


share resources 
on the same bus since 
transfers 


via the bus proceed 
asynchronously. 
Thus, trans- 
fer speed 
is dependent 
on transmitting 
and re- 


ceiving 
devices 
only. 
This 
design 
provides 
slow 


master 
modules 
from 
being 
handicapped 
in their 


attempts 
to gain control 
of the bus, but does not 


restrict 
the 
speed 
at which 
faster 
modules 
can 


transfer 
data via the same bus. The most obvious 
applications 
for the 
master-slave 
capabilities 
of 


the 
bus are multiprocessor 
configurations, 
high 
speed 
direct 
memory 
access 
(DMA) operations, 


and high speed 
peripheral 
control, 
but are by no 
means 
limited 
to these three. 


Programmable Timers 


The iSBC 80/24 board provides 
three independent, 


fully 
programmable 
16-bit 
interval 
timers/event 


counters 
utilizing 
the Intel 8253 Programmable 
In- 


terval Timer. Each counter 
is capable of operating 
in either 
BCD 
or 
binary 
modes. 
Two 
of 
these 
timers/counters 
are available 
to the systems 
de- 
signer 
to generate 
accurate 
time 
intervals 
under 
software 
control. 
Routing 
for 
the 
outputs 
and 
gate/trigger 
inputs 
of two 
of these 
counters 
is 
jumper 
selectable. 
The outputs 
may be independ- 


ently routed to the 8259A Programmable 
Interrupt 
Controller, 
to the 
110 line drivers 
associated 
with 
the 8255A Programmable 
Peripheral 
Interface, 
or 
may be routed 
as inputs 
to the 8255A chip. 
The 


gate/trigger 
inputs 
may 
be routed 
to 
110 termi- 


nators 
associated 
with 
the 
8255A 
or as output 
connections 
from 
the 
8255A. 
The 
third 
interval 
timer in the 8253 provides 
the programmable 
baud 
rate generator 
for the RS232C' USART serial 
port. 


In utilizing 
the 
iSBC 
80/24 
board, 
the 
systems 
designer 
simply 
configures, 
via 
software, 
each 


timer 
independently 
to 
meet 
system 
require- 


Function 


Interrupt on 
terminal 
count 


Programmable 
one-shot 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When terminal count is reached, 
an interrupt request is generated. 
This function is extremely useful 
for generation of real-time clocks. 


Outpflt goes low upon receipt of 
an external trigger edge' or soft- 
ware command and returns high 
when terminal count is reached. 
This function is retriggerable. 


Divide by N counter. The output 
will go low for one input clock cy- 
cle, and the period from one low- 
going pulse to the next is N times 
the input clock period. 


Output will remain high until one- 
half 
the count 
has been com- 


pleted, and go low for the other 
half of the count. 


Output 
remains high until 
soft- 


ware loads count (N). N counts 
after count is loaded, output goes 
low for one input clock period. 


Output goes low for one clock 
period N counts after rising edge 
on 
counter 
trigger 
input. 
The 


counter is retriggerable. 


On a jumper selectable basis, the 
clock 
input 
becomes an 
input 


from the external system. CPU 
may read the number of events oc- 
curring after the counting 
"win- 


dow" has been enabled or an in- 
terrupt may be generated after N 
events occur in the system. 


ments. 
Whenever 
a given- time 
delay or count 
is 
needed, 
software 
commands 
to 
the 
program- 
mable 
timers/event 
counters 
select 
the 
desired 
function. 
Seven functions 
are available, 
as shown 
in Table 2. The contents 
of each counter 
may be 
read at any time 
during 
system 
operation 
with 
simple 
read operations 
for event counting 
applica- 
tions, and special 
commands 
are included 
so that 
the contents 
of each counter 
can be read "on the 
fly". 


Interrupt Capability 


The iSBC 80/24 board provides vectoring 
for 12 in- 


terrupt 
levels. 
Four of these 
levels 
are handled 
directly 
by the interrupt 
processing 
capability 
of 
the 8085A-2 CPU and represent 
the four highest 
priority 
interrupts 
of the 
iSBC 80/24 board. 
Re- 
quests are routed to the 8085A-2 interrupt 
inputs- 
TRAP, RST 7.5, RST 6.5, and RST 5.5 (in decreas- 
ing order 
of priority), 
each of which 
generates 
a 
call 
instruction 
to a unique 
address 
(TRAP: 24H; 


RST 7.5: 3CH; RST 6.5: 34H; and RST 5.5: 2CH). An 
8085A-2 
JMP 
instruction 
at 
each 
of 
these 
ad- 
dresses 
then provides 
linkage to interrupt 
service 


routines 
located 
independently 
anywhere 
in mem- 


ory. All interrupt 
inputs 
with the exception 
of the 


trap 
interrupt 
may be masked 
via software. 
The 


trap interrupt 
should 
be used for conditions 
such 


as power-down 
sequences 
which 
require immedi- 
ate attention 
by the 8085A-2 CPU. The Intel 8259A 
Programmable 
Interrupt 
Controller 
(PIC) provides 


vectoring 
for the 
next 
eight 
interrupt 
levels. 
As 


shown 
in Table 3, a selection 
of four priority 
proc- 


essing modes is available to the systems 
designer 


for use in designing 
request 
processingconfigu- 


rations 
to match system 
requirements. 
Operating 
mode and priority 
assignments 
may be reconfig- 


ured dynamically 
via software 
at any time during 


system 
operation. 
The PIC accepts 
interrupt 
re- 


quests 
from the programmable 
parallel 
and serial 


I/O interfaces, 
the programmable 
timers, 
the sys- 


tem 
bus, 
iSBX 
bus, 
or directly 
from 
peripheral 


equipment. 
The PIC then determines 
which 
of the 


incoming 
requests 
is of the highest 
priority, 
deter- 


mines 
whether 
this 
request 
is of higher 
priority 


than the level currently 
being serviced, 
and, if ap- 


propriate, 
issues 
an interrupt 
to 
the 
CPU. Any 


combination 
of interrupt 
levels 
may be masked, 
via software, 
by storing 
a single 
byte in the inter- 
rupt mask register 
of the PIC. The PIC generates 
a 


unique 
memory 
address 
for each interrupt 
level. 


These addresses 
are equally spaced at intervals 
of 


4 or 
8 (software 
selectable) 
bytes. 
This 
32 or 


64-byte block may be located 
to begin at any 32 or 


64-byte 
boundary 
in 
the 
65,536-byte 
memory 
space. A single 
8085A-2 JMP 'instruction 
at each 
of these addresses 
then provides 
linkage to locate 
each interrupt 
service 
routine 
independently 
any- 


where in memory. 


Mode 
Operation 


Fully nested 
Interrupt request line priorities fixed 
at 0 as highest, 7 as lowest. 


Autorotating 
Equal priority. Each level, after re- 
ceiving service, becomes the lowest 
priority level until next interrupt oc- 
curs. 


Specific 
System software assigns lowest pri- 


priority 
ority level. Priority of all other levels 
based in sequence numerically on 
this assignment. 


Polled 
System software examines priority- 
encoded system interrupt status via 
interrupt status register. 


Interrupt Request Generation 


Interrupt 
requests 
may originate 
from 23 sources. 


Two jumper 
selectable 
interrupt 
requests 
can be 


generated 
by each 
iSBX 
MULTIMODULE 
board. 


Two jumper 
selectable 
interrupt 
requests 
can be 


automatically 
generated 
by each 
programmable 


peripheral 
interface 
when a byte of information 
is 


ready to be transferred 
to the CPU (i.e., input 
buf- 


fer is full) or a byte of information 
has been trans- 


ferred to a peripheral 
device (i.e., output 
buffer 
is 


empty). 
Three 
jumper 
selectable 
interrupt 
re- 


quests 
can 
be automatically 
generated 
by the 


USART when a character 
is ready to be transferred 


to the CPU (i.e., receiver 
channel 
buffer 
is full), a 


character 
is 
ready 
to 
be 
transmitted 
(i.e., 
the 


USART is ready to accept 
a character 
from 
the 


CPU), or when 
the transmitter 
is empty 
(i.e., the 


USART has no character 
to transmit). 
A jumper 


selectable 
request 
can be generated 
by each of 


the programmable 
timers. 
Nine interrupt 
request 


lines are available 
to the user for direct 
interface 


to 
user 
designated 
peripheral 
devices 
via 
the 


MUL T1BUS system 
bus. A power·fail 
signal 
can 


also be selected 
as an interrupt 
source. 


Power· Fail Control 


A power-fail 
interrupt 
may be detected 
through 


the AC-Iow signal generated 
by the power supply. 


This 
signal 
may 
be configured 
to 
interrupt 
the 


8085A-2 CPU to initiate 
an orderly 
power down in- 


struction 
sequence. 


MULTIBUS System Expansion 
Capabilities 


Memory 
and I/O capacity 
may be expanded 
and 


additional 
functions 
added using Intel MULTIBUS 


system 
compatible 
expansion 
boards. 
Memory 


may be expanded 
to 65,536 bytes by adding 
user 


specified 
combinations 
of RAM boards, 
EPROM 


boards, or combination 
boards. Input/output 
capa- 


city 
may be increased 
by adding 
digital 
1/0 and 


analog 
1/0 expansion 
boards. 
Mass storage 
capa- 


bility 
may be achieved 
by adding 
single 
or double 


density 
diskette 
or hard disk 
controllers 
as sub- 
systems. 
Expanded 
communication 
needs can be 


handled 
by communication 
controllers. 
Modular 


expandable 
backplanes 
and card cages are avail- 
able to support 
multiboard 
systems. 


Real-Time Software 


The iRMX™ 80 executive, 
which contains 
all major 


real-time 
facilities 
including 
priority-based 
system 


resource 
allocation, 
intertask 
communication 
and 


control, 
interrupt 
driven 
control 
for standard 
1/0 


devices, 
and 
interrupt 
handling, 
occupies 
2K 


bytes of memory 
which 
can be stored 
on-board 
in 


EPROM. Optional 
linkable 
and relocatable 
modu- 
les for console 
control 
(CRT or ny), disk file sys- 
tem, and analog subsystems 
are provided 
with the 


iRMX 80 package. 
These 
facilities 
eliminate 
the 


need for users to design 
and implement 
applica- 
tion specific 
executives, 
greatly 
simplifying 
appli- 


cation 
design 
and reducing 
development 
time and 


risk. 


System 
Development 
Capability 


The development cycle of iSSC 80/24-based products 
may be significantly 
reduced 
using 
Intel's 
system 


development 
tools available today. For those not re- 


quiring hardware emulation capability, Intel provides a 
new low cost microcomputer 
development 
system. 


The iPDS, Personal Development System, provides low 
cost system development 
for iSSC 80/24 
board, while 


at the 
same 
time 
providing 
personal 
computer 


capability for the engineer. The Intellec Series II family 
of compatible 
microcomputer 
development 
systems 


provides 
a range of capability 
from a low cost disk- 


based edit debug workstation 
to a high performance, 
fully compatible 
hard-disk-based 
software 
develop- 


ment system. A unique in-circuit emulator (ICE-85A) 
option 
provides 
the capability 
of developing 
and 


debugging software directly on the iSSC 80/24 
board. 


Programming 
Capability 


PUM·80-lntel's 
high 
level 
system 
programming 


language, 
PUM, 
is also 
available 
as a resident 


Intellec 
microcomputer 
development 
system 
op- 


tion. 
PUM provides 
the capability 
to program 
in a 


natural, 
algorithmic 
language 
and eliminates 
the 


need to manage 
register 
usage or allocate 
mem- 


ory. 
PUM 
programs 
can 
be written 
in a much 


shorter 
time than assembly 
language 
programs. 


FORTRAN·80-For 
applications 
requiring 
compu- 


tational 
and formatted 
I/O capabilities, 
the ANSI 


77 standard 
high level FORTRAN-80 
programming 


language 
is available 
as a resident 
option 
of the 


Intellec 
system. 
The 
FORTRAN 
compiler 
pro- 


duces 
relocatable 
object 
code that may be easily 


linked 
with 
PUM or assembly 
language 
program 


modules. 
In addition, 
the iSBC 801 FORTRAN-80 


Run-Time 
Package is a complete, 
ready-to-use 
set 


of 
linkable 
object 
modules 
which 
are 
fully 


compatible 
with 
iRMX 80 systems. 
The modules, 


when combined 
with 
the FORTRAN-80 
coded 
ap- 


plication, 
provide the appropriate 
interfaces 
to the 


disk 
file 
and terminal 
I/O of iRMX 80, and to the 
iSBC 
310A 
Math 
Unit 
for 
applications 
requiring 


high speed math. 


BASIC·80-A 
high 
level 
language 
interpreter 
is 


available 
with 
extended 
disk 
capabilities 
which 


operates 
under the iRMX 80 Real-Time 
Multitask- 


ing Executive 
and translates 
BASIC-80 source 
pro- 


grams 
into 
an 
internally 
executable 
form. 
This 


language 
interpreter, 
provided 
as a set of linkable 


object 
modules, 
is ideally 
suited 
to the OEM who 
requires 
a pass through 
programming 
language. 


The BASIC-80 
programs 
may be created, 
stored, 


and 
interpreted 
on the 
iSBC 
80-based 
systems 


using 
the iSBC 802 BASIC-80 Configurable 
iRMX 


80 Disk-Based 
Interpreter. 
The 
iSBC 
802 
Inter- 


preter has a complete 
ready-to-use 
set of linkable 


object 
modules 
'vI(hich are fully compatible 
with In- 


tel's 
iRMX 
80 Real-Time 
Multitasking 
Executive 


Software. 
The modules 
provide 
interfaces 
to disk 
file and terminal 
I/O, software 
floating 
point, 
or in- 
terface 
to other 
routines 
provided 
by the user. 


Word Size 


Instruction-8, 
16, or 24 bits 


Data-8 
bits 


Cycle Time 


Basic 
Instruction 
Cycle 
826 nsec (4.84 MHz operating 
frequency) 


1.65 I"sec (2.42 MHz operating 
frequency) 


NOTE: 
Basic instruction cycle is defined as the fastest instruction 
(i.e., four clock cycles). 


Memory Addressing 


On-Board 
EPROM 
O-OFFF using 
2708, 2758 (1 wait state) 


0-1FFF 
using 
2716 (1 wait state) 


0-3FFF 
using 
2732 (1 wait state) 
using 
2732A (no wait states) 


0-7FFF 
using 
2764A (no wait states) 


On-Board 
RAM 
3000-3FFF 
with 
no RAM expansion 
2000-3FFF 
with 
optional 
RAM (iSBC 301 board) 


NOTE: 
Default configuration-may 
be reconfigured to top end of any 


16K boundary. 


inter 


Memory 
Capacity 


On-Board 
EPROM 


32K bytes 
(sockets 
only) 


May be added 
in 1K (using 
Intel 
2708 or 2758), 2K 


(using 
Intel 
2716), 
4K 
(using 
Intel 
2732), 
or 
8K 


(using 
Intel 
2764) byte 
increments. 


On-Board 
RAM 


4K bytes 
(8K bytes 
using 
iSBC 
301 4K byte 
RAM 
MUL TIMOOULE 
Board) 


Off· Board 
Expansion 


Up to 
64K 
bytes 
using 
user 
specified 
combina- 


tions 
of RAM, 
ROM, and 
EPROM. 


Up to 128K bytes 
using 
bank select 
control 
via I/O 
port 
and 2 jumper 
options. 


May be disabled 
using 
PROM 
ENABLE 
via I/O port 
and 
jumper 
option, 
resulting 
in 
off-board 
RAM 
overlay 
capability. 


1/0 Addressing 


On· Board 
Programmable 
I/O 


Device 
I/O Address 


8255A NO.1 


Port A 
E4 
Port B 
E5 
Port C 
E6 


Control 
E7 


8255A NO.2 


Port A 
E8 


Port B 
E9 


Port C 
EA 


Control 
EB 


8251A 
Data 
EC, EE 


Control 
ED, EF 


iSBX MULTI MODULE J::> 
MCSO 
CO-C7 
MCS1 
C8-CF 


iSBX MULTIMODULE J6 
MCSO 
FO-F7 


MCS1 
F8-FF 


iSBX 
MUL TIMODULE 
- 
2 iSBX 
~UL TIMOOULE 
Boards 


Synchronous-5-8 
bit 
characters; 
internal 
or ex- 


ternal 
character 
synchronization; 
automatic 
sync 


insertion 


Asynchronous-5-8 
bit characters; 
break 
charac- 


ter generation; 
1, 1V2, or 2 stop 
bits; 
false 
start 
bit 


detectors 


Output 
Baud 
Rate (Hz) 
Frequency 
Synchronous 
Asynchronous 
in kHz 


+16 
+64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 
1.76 
1760 
110 - 


NOTE: 
Frequency selected by I/O write of appropriate 
16-bit frequency 


factor to baud rate register. 


Register 
Address 
(hex 
notation, 
I/O 
address 


space) 


DE 
Baud 
rate register 


NOTE: 
Baud rate factor (16 bits) is loaded as two sequential output op- 
erations to same address (DEH). 


Addresses 
for 8259A 
Registers 
(hex notation, 
I/O 


address 
space) 


OA or 08 
Interrupt 
request 
register 
OA or 08 
In-service 
register 
DB or 09 
Mask 
register 
OA or 08 
Command 
register 
DB or 09 
Block 
address 
register 
OA or 08 
Status 
(polling 
register) 


NOTE: 
Several registers have the same physical address; sequence of 
access and one data bit of control word determine which regis- 
ter will respond. 


Interrupt 
levels 
routed 
to 8085A-2 
CPU automatic- 


ally vector 
the 
processor 
to unique 
memory 
loca- 


tions: 


Interrupt 
Memory 
Priority 
Type 
Input 
Address 


TRAP 
24 
Highest 
Non-maskable 


RST 7.5 
3C 
~ 


Maskable 


RST 6.5 
34 
Maskable 


RST 5.5 
2C 
Lowest 
Maskable 


Register 
Addresses 
(hex 
notation, 
I/O address 
space) 


DF 
Control 
register 
DC 
Timer 0 
DD 
Timer 1 
DE 
Timer 2 


NOTE: 


Timer 
counts 
loaded 
as 
two 
sequential 
output 
operations 
to 


same 
address 
as 
given. 


Input Frequencies 


Reference: 
1.0752 MHz ± 0.1 % (0.930 /lsec 
peri- 
od, nominal) 
Event Rate: 
1.1 MHz max. 


Function 
Single 
Timer/Counter 
Dual 
Timer/Counter 


(Two 
Timers 
Cascaded) 


Min. 
Max. 
Min. 
Max. 


Real·Time 
1.86 Jlsec 
60.948msec 
3.72 p,sec 
1.109 hrs 
Interrupt 


Programmable 
1.86/lsec 
60.948 msec 
3.72 Jlsec 
1.109 hrs 


One·Shol 


Rate 
16.407 Hz 
537.61 kHz 
0.00025 Hz 
268.81 kHz 
Generator 


Square-Wave 
16.407 Hz 
537.61 kHz 
0.00025 Hz 
268.81 kHz 
Rate 
Generator 


Software 
1.86 Jlsec 
60.948 msec 
3.72 J4sec 
1.109 hrs 
Triggered 
Strobe 


Hardware 
1.86 Jlsec 
60.948 msec 
3.72 Jlsec 
1.109 hrs 


Triggered 
Strobe 


NOTE: 


Input 
frequency 
to timers 
is 1.0752 
MHz 
(default 
configuration). 


Interfaces 


MUL TIBUS-AII 
signals 
TTL compatible 


iSBX Bus-All 
signals 
TTL compatible 


Parallel I/O-All 
signals 
TTL compatible 


Seria11/0-RS232C 
compatible, 
configurable 
as a 
data set or data terminal 


Timer-All 
signals 
TTL compatible 


Interrupt 
Requests-Ail 
TTL compatible 


System 
Clock (8085A·2 CPU) 


4.84 or 2.42 MHz ± 0.1 % (jumper selectable) 


Auxiliary 
Power 


An auxiliary 
power bus is provided 
to allow 
sepa- 
rate power to RAM for systems 
requiring 
battery 


auxiliary 
RAM power bus is made via jumpers 
on 


the board. 


Doubl. 
Centers 
Intertece 
Sided Pins 
(In.) 
Meting 
Connectors" 


(qty) 


MULTIBUS 
86 
0.156 
ELFAB 
BS1562043PBB 


System 
Viking 
2KH43/9AMK12 


Bus 
Soldered 
PCB Mounl 


EDAC 337068540201 
ELFAB 
BWl562D43PBB 


EDAC 337068540202 
ELFAB 
BW1562A43PBB 


Wire Wrap 


Auxiliary 
60 
0.100 
EDAC 345060524802 


Bus 
ELFAB 
BS1020A30PBB 


EDAC 345060540201 
ELFAB 
BW1020D30PBB 


Wire Wrap 


iSBX Bus 
36 
0.100 
iSBX 960-5 


(2) 


ParailelllO 
50 
0.100 
3M 3415-001 
Flat Crimp 


(2 ) 
GTE Sylvania 
6AD01251A1DD 
Soldered 


Serial 
110 
26 
0.100 
AMP 
15637151 


EDAC 345026520202 


PCB Soldered 
3M 3462-0001 
AMP 88373-5 Flat Crimp 


Memory 
Protect 


An active-low 
TTL compatible 
memory protect 
sig- 


nal 
is 
brought 
out 
on 
the 
auxiliary 
connector 


which, when asserted, 
disables 
read/write 
access 


to RAM memory 
on the board. This input 
is pro- 


vided for the protection 
of RAM contents 
during 


system 
power-down 
sequences. 


Line Drivers and Terminators 


I/O Drivers-The 
following 
line drivers 
and termi- 


nators are all compatible 
with the I/O driver sock- 


ets on the iSBC 80/24 Board: 


Driver 
Characteristic 
Sink Current (mA) 


7438 
I,OC 
48 


7437 
1 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


NOTE: 


I = inverting; 
NI = non-inverting; 
OC = open 
collector. 


Ports 
E4 and E8 have 32 mA totem-pole 
drivers 


and 1K terminators. 


I/O Terminators-220n/330n 
divider 
or 1 kn pullup 


_______ 
~-! 
l~ 


I 


1 k~! (iSBX 902 OPTION) 
1 kU 
+5V-------~NV'~--------- 


Function 
Characteristic 
Sink Current (mA) 


Data 
Tri-State 
32 


Address 
Tri·State 
32 


Commands 
Tri-State 
32 


Physical 
Characteristics 


Width-12.00 
in. (30.48 em) 
Height-6.75 
in. (17.15 em) 
Depth-0.50 
in. (1.27 em) 
Weight-12.64 
oz. (354 gm) 


Electrical 
Characteristics 


DC Power 
Requirements 


Configuration 


Current 
Requirements 


Vcc=+SV 
Voo= 
+12V 
VBB=-SV 
VAA=-12V 


::5% (max) 
;:5% (max) 
±5%(max) 
±5%(max) 


Without 
3.34A 
40 mA 
- 
20 mA 
EPROM' 


RAM Only2 
0.14A 
- 
- 
- 


With 
3.34A 
140 mA 
- 
120 mA 
iSBC 5303 


With 4K 
EPROM' 
3.74A 
300 mA 
180mA 
20mA 


(using 2708) 


With 4K 
EPROM' 
4.43A 
40 mA 
- 
20 mA 


(using 2758) 


With 8K 
EPROM' 
4.43A 
40 mA 
- 
20mA 


(using 2716) 


With 
16K 
EPROM' 
4.71A 
40 mA 
- 
20mA 


(using 2732) 


With 32K 
EPROM' 
4.71A 
40 mA 
- 
20 mA 


(using 2764) 


NOTES: 
1. Does not include power for optional 
EPROM, 1/0 drivers, 


and I/O terminators. 


2. RAM chips powered via auxiliary power bus. 
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via serial port connector. 


4. Includes power required for four EPROM chips, and I/O ter- 


minators installed for 16 1/0 lines; all terminator inputs low. 


Environmental 
Characteristics 


Operating 
Temperature-O°C 
to 55°C 


Reference 
Manual 


142648·001-iSBC 
80/24 Single 
Board 
Computer 


Hardware 
Reference 
Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from any Intel sales rep- 


resentative, 
distributor 
office 
or from 
Intel Litera· 


ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 


Clara, California 
95051. 


Part Number 


SBC 80/24 


Description 


Single 
Board Computer 


iSBC 80120·4 (or pSBC 80120·4*) 
SINGLE 
BOARD COMPUTER 


• Sockets for up to 8K bytes of erasable 
reprogram mabie or masked read only . 
memory 


• 48 programmable parallel I/O lines with 
sockets for interchangeable line drivers 
and terminators 


• Programmable synchronous/asynchro· 
nous RS232C compatible serial 
interface with fully software selectable 
baud rate generation 


• Full MULTIBUS control logic allowing 


up to 16 masters to share system bus 


• Two programmable 16·bit BCD and 


binary timers 


• Eight·level programmable interrupt 


control 


• Compatible with optional memory and 
I/O expansion boards 


• Auxiliary power bus, memory protect, 


and power-fail interrupt control logic 
provided for battery backup RAM 
requirements 


The iSBC 80/20-4 Single 
Board Computer 
is a member 
of Intel's 
complete 
line of OEM computer 
systems 
which 
take 
full 
advantage 
of Intel's 
LSI technology 
to provide 
economical, 
self-contained 
computer-based 
solutions 
for OEM 
applications. 
Each iSBC 80/20-4 is a complete 
computer 
system 
on a single 
6.75 x 12.00-inch 
printed 
circuit 
card. The 
CPU, system 
clock, 
read/write 
memory, 
nonvolatile 
read only 
memory, 
I/O. ports 
and drivers, 
serial 
communications 
interface, 
priority 
interrupt 
logic, 
two 
programmable 
timers, 
MULTIBUS 
control 
logic, 
and bus expansion 
drivers 
all 
reside 
on each board. 


Intel's powerful 8-bit n-channel MOS 8080A CPU, fabri- 
cated on a single lSI chip, is the central processor for 
the iSSC 80/20-4.The 8080A contains six 8-bit general 
purpose registers and an accumulator. The six general 
purpose registers may be addressed individually or in 
pairs, providing both single and double precision opera- 
tors. Minimum instruction execution time is 1.86micro- 
seconds. A block diagram of iSSC 80/20-4 functional 
components is shown in Figure 1. 


The 8080A has a 16-bit program counter which allows 
direct addressing of up to 65,536 bytes of memory. An 
external stack, located within any portion of read/write 
memory, may be used as a last-in/first-out storage area 
for the contents of the program counter, flags, accumu- 
lator, and all of the six general purpose registers. A 
16-bit stack pointer controls 
the addressing of this 
external staCk. This stack provides subroutine nesting 
bounded only by memory size. 


The iSSC 80/20-4contains 4K bytes of static read/write 
memory using Intel low power static RAMs. All on-board 
RAM read and write operations are performed at maxi- 
mum processor speed. Power for on-board RAM mem- 
ory is provided on an auxiliary power bus, and memory 
protect logic is included for battery backup RAM re- 
quirements. Sockets for up to 8K bytes of nonvolatile 
read only memory are proVided on the board. Readonly 


memory may be added in 1K·byte increments using Intel 
2708 erasable and electrically 
reprogrammable ROMs 


(EPROMs),or read only memory may be added in 2K·byte 
increments using Intel 2716 EPROMs.All on-board ROM 
read operations are performed at maximum processor 
speed. 


The iSSC 80/20-4contains 48 programmable parallel I/O 
lines implemented using two Intel 8255 programmable 
peripheral interfaces. The system software is used to 
configure the I/O lines in any combination of the uni- 
directional 
input/output, 
and bidirectional 
ports indi- 
cated in Table 1. Therefore, the I/O interface may be 
customized to meet specified peripheral requirements. 
In order to take full advantage of the large number of 
possible I/O configurations, sockets are provided for in- 
terchangeable I/O line drivers and terminators. Hence, 
the flexibility of the I/O interface is further enhanced by 
the capability of selecting the appropriate combination 
of optional line drivers and terminators to provide the 
required sink current, polarity, and drive/termination 
characteristics 
for each application. The 48 program- 


mable I/O lines and signal ground lines are brought out 
to two 50-pin edge connectors 
that mate with 
flat, 


woven, or round cable. 


A 
programmable 
communications 
interface 
using 


Intel's 8251 Universal Synchronous/Asynchronous 
Re- 


ceiver/Transmitter (USART) is contained on the iSSC 


80/20-4board. A software selectable baud rate generator 
provides the USART with all common communications 
frequencies. The USARTcan be programmed by the sys- 
tem software to select the desired asynchronous or syn- 
chronous serial data transmission technique (including 
IBM Bi-Sync). The mode of operation (i.e., synchronous 
or asynchronous), data format, control character parity, 
and baud rate are all under program control. The 8251 
provides 
full 
duplex, 
double-buffered 
transmit 
and 


receive capability. Parity, overrun, and framing error de- 
tection are all incorporated in the USART.The RS232C 
compatible interface on each board, in conjunction with 
the USART,provides a direct interface to RS232Ccom- 
patible terminals, cassettes, and asynchronous and syn- 
chronous modems. The RS232Ccommand lines, serial 
data lines, and signal ground line are brought out to a 
26-pin edge connector that mates with RS232Ccompati- 
ble flat or round cable. 


Multimaster 
Capability 


The iSBC 80/20-4 is a full computer on a single board 
with resources capable of supporting the majority of 
OEM system requirements. For those applications 
re- 


quiring additional processing capacity and the benefits 
of multiprocessing (i.e., several CPUs and/or controllers 
logically share system tasks with communication over 
the system bus), the iSBC 80/20-4 provides full MULTI- 
BUS arbitration control logic. This control logic allows 
up to three iSBC 80/20-4 or high speed controllers to 
share the system bus in serial (daisy chain) priority 
fashion, and up to 16 masters may share the system bus 
with the addition of an external priority network. Once 


bus control is attained, a bus bandwidth of up to 5M 
bytes/sec may be achieved. 


The bus controller 
provides its own clock which 
is 


derived independently from the processor clock. This 
allows different speed controllers to share resources on 
the same bus, and transfers via the bus proceed asyn- 
chronously. Thus, transfer speed is dependent on trans- 
mitting and receiving devices only. This design prevents 
slow master modules from being handicapped in their 
attempts to gain control of the bus, but does not restrict 
the speed at which faster modules can transfer data via 
the same bus. Once a bus request is granted, single or 
multiple read/write transfers can proceed at a maximum 
rate of 5 million data words per second. The most obvi- 
ous applications for the master-slave capabilities of the 
bus are multiprccessor 
configurations, 
high 
speed 


direct-memory-access (DMA)operations and high speed 
peripheral control, but are by no means limited to these 
three. 


Programmable 
Timers 


The iSBC 80/20-4 board provides three fully program- 
mable and independent BCD and binary 16-bit interval 
timers/event counters utilizing an Intel 8253 Program- 
mable Interval Timer. Two of these timers/counters are 
available to the systems designer to generate accurate 
time intervals under software control. Routing of these 
counters is jumper selectable. Each may be independ- 
ently routed to the programmable interrupt controller, 
the 110 line drivers and terminators, or outputs from the 
8255 programmable peripheral interfaces. The third in- 
terval timer in the 8253 provides the programmable baud 


Mode of Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched & 
Latched 
Latched & 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X' 
I----- 


4 
X 
X 
X' 


4 
8 
X 
X 
X 
X 
X 


5 
8 
, 
X 
X 
X 
X 


6 
4 
X 
X 
X2 


4 
X 
X 
X2 


Notes 
1. Part'of port J musl be used as a control 
port when either port 1 or port 2 are used as a latched and strobed input or a latched and strobed output 


port or port 1 IS used as a bidirectional 
port. 


2. Part of port 6 must be used as a control 
port when either port 4 or port 5 are used as a latched and strobed input or a latched and strobed output 
port or port 4 is used as a bidirectional 
port. 


rate 
generator 
for 
the 
iSSC 
80/20-4 
RS232C 
USART 
serial 
port. 
In utilizing 
the 
iSSC 
80/20-4, 
the 
systems 
designer 
simply 
configures, 
via software, 
each timer 
in- 


dependently 
to meet 
system 
requirements. 
Whenever 
a 
given 
time 
delay 
or 
count 
is 
needed, 
software 
com- 


mands 
to 
the 
programmable 
timers/event 
counters 
select 
the 
desired 
function. 
Seven 
functions 
are avail- 


able, as shown 
in Table 2. The contents 
of each counter 
may be read at any time 
during 
system 
operation 
with 
simple 
read operations 
for event 
counting 
applications, 


and 
special 
commands 
are 
included 
so 
that 
the 
con- 
tents 
of each counter 
can be used 
"on 
the fly". 


Function 


Interrupt 
on 


terminal 
count 


Programmable 
one-shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When 
terminal 
count 
is reached, 
an 
interrupt 
request 
is generated. 
This 
function 
is 
extremely 
useful 
for 
generation 
of real-time 
clocks. 


Output 
goes 
low upon receipt 
of an 
external 
trigger 
edge 
or 
software 
command 
and 
returns 
high 
when 
terminal 
count 
is 
reached. 
This 
function 
is retriggerable. 


Divide 
by N counter. 
The output 
will 
go 
low 
for 
one 
input 
clock 
cycle, 


and the 
period 
from 
one 
low-going 
pulse 
to the next 
is N times 
the in- 
put clock 
period. 


Output 
will 
remain 
high 
until 
one- 


half the count 
has been completed, 


and go low for the other 
half of the 
couni. 


Output 
remains 
high 
until 
software 
loads 
count 
(N). 
N 
counts 
after 
count 
is loaded, 
output 
goes low for 
one input 
clock 
period. 


Output 
goes 
low 
for 
one 
clock 
period 
N counts 
after rising 
edge on 
counter 
trigger 
input. 
The 
counter 


is retriggerable. 


On a jumper 
selectable 
basis, 
the 
clock 
input 
becomes 
an input 
from 
the external 
system. 
CPU may read 


the 
number 
of 
events 
occurring 
after 
the 
counting 
"window" 
has 
been enabled 
or an interrupt 
may be 
generated 
after 
N events 
occur 
in 
the system. 


Interrupt 
Capability 


Operation and Priority Assignments - 
An 
Intel 
8259 
Programmable 
Interrupt 
Controller 
(PIC) provides 
vec- 


toring 
for eight 
interrupt 
levels. 
As shown 
in Table 
3, a 


selection 
of four 
priority 
processing 
modes 
is available 


to 
the 
systems 
designer 
so that 
the 
manner 
in which 
requests 
are 
processed 
may 
be confiQured 
to 
match 


system 
requirements. 
Operating 
mode 
and 
priority 


assignments 
may be reconfigured 
dynamically 
via soft- 


ware 
at 
any 
time 
during 
system 
operation. 
The 
PIC 


accepts 
interrupt 
requests 
from 
the 
programmable 


parallel 
and 
serial 
110 
interfaces, 
the 
programmable 


timers, 
the 
system 
bus, 
or 
directly 
from 
peripheral 


equipment. 
The 
PIC 
then 
determines 
which 
of 
the 


incoming 
requests 
is of the highest 
priority, 
determines 


whether 
this 
request 
is of higher 
priority 
than 
the level 


currently 
being 
serviced, 
and 
if appropriate, 
issues 
an 


interrupt 
to the CPU. Any combination 
of interrupt 
levels 


may be masked 
through 
storage 
via software, 
of a single 


byte to the interrupt 
register 
of the PIC. 


Mode 


Fully 
nested 


Auto- 
rotating 


Operation 


Interrupt 
request 
line 
priorities 
fixed 
at 0 


as highest, 
7 as lowest. 


Equal 
priority. 
Each 
level, 
after 
receiving 


service, 
becomes 
the lowest 
priority 
level 


until 
the next 
interrupt 
occurs. 


System 
software 
assigns 
lowest 
priority 


level. 
Priority 
of all other 
levels 
based 
in 


sequence 
numerically 
on this assignment. 


System 
software 
examines 
priority-en- 


coded 
system 
interrupt 
status 
via 
inter- 


rupt 
status 
register. 


Specific 
priority 


Interrupt Addressing - 
The 
PIC 
generates 
a unique 


memory 
address 
for each 
interrupt 
level. These 
addres- 


ses are equally 
spaced 
at intervals 
of 4 or 8 (software 


selectable) 
bytes. 
This 
32- or 
64-byte 
block 
may 
be 


located 
to begin 
at any 32- or 64-byte 
boundary 
in the 


65,536-byte 
memory 
space. 
A single 
8080 jump 
instruc- 


tion at each of these 
addressed 
then 
provides 
linkage 
to 


locate 
each interrupt 
service 
routine 
independently 
any- 


where 
in memory. 


Interrupt Request Generation - 
Interrupt 
requests 
may 


originate 
from 26 sources. 
Four jumper 
selectable 
inter- 


rupt 
requets 
can be automatically 
generated 
by the pro- 


grammable 
peripheral 
interface 
when 
a byte of informa- 


tion 
is ready to be transferred 
to the CPU (i.e., input 
buf- 


fer is full) or a byte of information 
has been transferred 


to a peripheral 
device 
(i.e., output 
buffer 
is empty). 
Two 


jumper 
selectable 
interrupt 
requests 
can be automatic- 


ally 
generated 
by the USART when 
a character 
is ready 


to be transfer 
to the CPU (i.e., receive 
channel 
buffer 
is 


full), or a character 
is ready to be transmitted 
(i.e., trans- 


mit 
channel 
data 
buffer 
is empty). 
A jumper 
selectable 


request 
can be generated 
by each of the programmable 


timers. 
Nine additional 
interrupt 
request 
lines 
are avail- 


able 
to the 
user 
for direct 
interface 
to user designated 


peripheral 
devices 
via the 
system 
bus, 
and eight 
inter- 


rupt 
request 
lines 
may 
be jumper 
routed 
directly 
from 


peripherals 
via the parallel 
110 driverlterminator 
section. 


Power-Fail Control - 
ContrOl 
logic 
is also 
included 
for 


generation 
of a power-fail 
interrupt 
which 
works 
in con- 


junction 
with 
the 
AC-Iow 
signal 
from 
iSSC 
635 Power 


Supply 
or equivalent. 


Expansion 
Capabilities 


Memory and I/O capacity may be expanded and addi· 
tional functions added using Intel MULTIBUS compati· 
ble expansion boards. High speed integer and floating· 
point arithmetic capabilities may be added by using the 
iSBC 310A High Speed Mathematics Unit. Memory may 
be expanded to 65,536 bytes by adding user specified 
combinations of RAM boards, EPROM boards, or com· 
bination boards. Input/output capacity may be increased 
by adding digital I/O and analog I/O expansion boards. 
Mass storage capability 
may be achieved by adding 


single or double density diskette controllers as subsys· 
tems. Modular expandable backplanes and cardcages 
are available to support multiboard systems. 


Real·Tlme 
Software' 


The iSBC aO/20·4is totally compatible with Intel's iRMX 
ao Real·Time Multi·Tasking 
Executive. 
iSBC aO/20·4 
based user programs (tasks) can take advantage of the 
iRMX ao executive to do all nllcessary scheduling, inter· 
task communication, 
and memory space allocation. 
iRMX ao also provides standard I/O support software 
such as disk file handling, Intel analog board handling, 
and terminal handling. 


System 
Development 
Capability 


The development cycle of iSBC aO/20-4-basedproducts 
may be significantly reduced using Intel's system devel- 
opment tools available today. For those not requiring 
hardware emulation capability, Intel prOVidesa new low 
cost microcomputer 
development system. The iPDS, 
Personal 
Development 
System, 
provides 
low cost 


system development for the iSBC aO/20-4board, while at 
the same time providing personal computer capability 
for the engineer. The Intellec Series II family of compat- 
ible microcomputer 
development systems provides a 


range of capability from a low cost disk-based edit debug 
workstation to a high performance, fully compatible hard· 


disk-based software development system. A unique in- 
circuit emulator (ICE-aO)option provides the capability 
of developing and debugging software directly on the 
iSSC aO/20-4board. 


Programming 
Capability 


PUM·ao - 
Intel's high level programming language, 


PUM, is also available as a resident Intellec microcom· 
puter development system option. PUM provides the 
capability to program in a natural, algorithmic language 
and eliminates the need to manage register usage or 
allocate memory. PUM programs can be written in a 
much shorter time than assembly langauge programs 
for a given application. 


FORTRAN·ao - 
For applications 
requiring computa· 


tional and formatted 
I/O capabilities, 
the high level 


FORTRAN·aOprogramming language is also available 
as a resident option of the Intellec system. The FOF\· 
TRAN compiler produces relocatable object code that 
may be easily linked with PUM or assembly language 
program modules. This gives the user a wide flexibility 
in developing software. 


BASlc·ao - 
A high level language interpreter 
with 


extended disk capabilities 
which operates under the 
RMXl80 Real·Time Multi·Tasking Executive and trans· 
lates BASIC·80source programs into an internally exe· 
cutable form. This language interpreter, prOVidedas a 
set of linkable object modules, is ideally suited to the 
OEM who requires a pass through programming Ian· 
guage. The BASIC·80 programs may'be created, stored 
and interpreted on the iSBC 80 based system. The 
BASIC·aOlanguage has a rich complement of state· 
ments, functions, and commands to program applica· 
tions requiring a full range of 1)string manipulation and 
disk 110 for data processing, 2) single and double preci· 
sion floating point and array handling for numeric analy· 
sis, or 3) port 
I/O with 
mask operations 
controlled 


through bit·wise Boolean logical operators. 


Word Size 
Instruction - 
a, 16, or 24 bits 


Data - 
8 bits 


Cycle Time 
Basic Instruction Cycle - 
1.86I'S 


Nole 
Basic instruction 
cycle is defined as the fastest instruction 
(Le., four 


clock cycles). 


Memory 
Addressing 
On·Board ROM/EPROM - 
O-OFFF (2708) or 0-1 FFF 


(2716) 


On·Board RAM - 
4K bytes ending on a 16K boundarY 


(e.g., 3FFFH, 7FFFH, BFFFH, ... 
FFFFH) 


Memory 
Capacity 


On·Board ROM/EPROM- 
8K bytes (sockets only) 


On·Board RAM - 
4K bytes 


Off·Board Expansion - 
Up to 65,536bytes in user speci· 


fied RAM, ROM, and EPROM 


I/O Addressing 


On·Board Programmable 110 (see Table 1) 


8255 NO.1 
8255 No.2 
8255 
8255 
Port 
No. 1 
No. 2 


Control 
Control 


1/0 Capacity 


Parallel 
- 
48 programmable 
lines 
(see Table 
1) 


Note 
Expansion 
to 504 input 
and 504 output 
lines can be accomplished 
using 


optional 
110 boards. 


Serial Communications 
Characteristics 


Synchronous 
- 
5-8 bit characters; 
internal 
or external 


character 
synchronization; 
automatic 
sync 
insertion 


Asynchronous 
- 
5-8 
bit 
characters; 
break 
character 


generation; 
1, 1'/2, or 2 stop bits; false start bit detection 


Frequency 
(k Hz) 
Blud 
RIte 
(Hz) 


(Softwlre 
Selectlble) 
Synchronous 
Asynchronous 


-16 
+64 


153.6 
- 
9600 
2400 


76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
.19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


Note 
Frequency 
selected 
by 110write of appropriate 
16·bit frequency 
factor 
to 


baud rate register. 


Register 
Address 
(hex notation, 
I/O address 
space) 


DE 
Baud rate register 


Note 
Baud rate factor (16 bits) IS loaded as two sequential 
output operations 


to same address (OEH). 


Interrupts 


Register 
Addresses 
(hex notation, 
I/O address 
space) 


DA 
Interrupt 
request 
register 


DA 
In-service 
register 


DB 
Mask register 
DA 
Command 
register 
DB 
Block 
address 
register 
DA 
Status 
(polling 
register) 


Note 
Several registers 
have the same physical 
address; sequence 
of a'ccess 


and one data bit of control word determine which register will respond. 


Timers 


Register 
Addresses 
(hex notation, 
I/O address 
space) 


OF 
Control 
register 
DC 
Timer 
1 


DO 
Timer 
2 


Note 


Timer 
counts 
loaded 
as two 
sequential 
output 
ope~tions 
to 
same 


address, 
as given 


" 


0 ••• 1TlmertCountllf 


Function 
Slngl~ 
Timer/Counter 
(Two Tim ••• 
CaacMled) 


Mln 
MI' 
Mln 
M. 


Aeal-time 
1.86 ,_ 
60.948 ms 
3.72 ,_ 
1.109 hr 
interrupt 


Programmable 
1.86 ,s 
60.948 m_ 
3.72,_ 
1.109 hr 


one-shot 


Aate generator 
16.407 Hz 
537.61 kHz 
0.00025 Hz 
268.81 kHz 


Square-wave 
16.407 Hz 
537.61 kHz 
0.00025 Hz 
268.31 kHz 


rate generator 


Software 
1.86,s 
60.948 m_ 
3.72 ,s 
1.109 hr 


triggered 
strobe 


Hardware 
1.86,s 
60.948 m_ 
3.72 ,s 
1.109 hr 


triggered 
strobe 


Interfaces 


Bus - 
All signals 
TIL 
compatible 
Parallel 
110 - 
All signals 
TIL 
compatible 
Interrupt 
Requests 
- 
All TIL 
compatible 
Timer 
- 
All signals 
TIL 
compatible 
Serial I/O - 
RS232C compatible, 
data set configuration 


System 
Clock (808OA CPU) 


2.1504 MHz 
±0.1% 


Auxiliary 
Power 


An auxiliary 
power 
bus 
is provided 
to allow 
separate 


power 
to RAM for systems 
requiring 
battery 
backup 
of 


read/write 
memory. 
Selection 
of 
this 
auxiliary 
RAM 


power 
bus is made via jumpers 
on the board. 


Memory 
Protect 


An active-low 
TIL 
compatible 
memory 
protect 
signal 
is 


brought 
out 
on 
the 
auxiliary 
connector 
which, 
when 


asserted, 
disables 
read/write 
access 
to RAM memory 
on 


the 
board. 
This 
input 
is provided 
for the protection 
of 


RAM 
contents 
during 
system 
power-down 
sequences. 


Doub •• 
Cente •• 
Intartlce 
Sided Pins 
(In.) 
MIUng 
Connectors· 


(qty) 


MULTIBUS 
86 
0.156 
ELFAB 
BSl562043PBB 


System 
Viking 
2KH4319AMK12 


Bus 
Soldered 
PCB Mount 


EDAC 337086540201 
ELFAB 
BWl562D43PBB 


EDAC 337086540202 
ELFAB 
BWl562A43PBB 


Wire Wrap 


Auxiliary 
60 
0.100 
EDAC 345060524802 


Bus 
ELFAB 
BS1020AJOPBB 


EDAC 345060540201 
ELFAB BW1020DJOPBB 


Wire Wrap 


Parallel 
110 
50 
0.100 
3M 3415-001 
Flat Crimp 


(2 ) 
GTE Sylvania 
6AD01251A1DD 
Soldered 


Serial 
1/0 
26 
0.100 
AMP 
15837151 


EDAC 345026520202 


PCB Soldered 


3M 3462-0001 
AMP 86373-5 Flat Crimp 


Ref.r.nce 


1.0752 MHz::!: 10% (0930~s 
penod, nominal) 


No •• 
MaXImum rate for external 
events In eyent counter 
functIon. 
·Note: 
Connectors 
compatible 
with those listed 
may also be used_ 


I/O Drivers - 
The following line drivers are all compati- 
ble with the I/O driver sockets on the iSBC 80/20-4. 


Driver 
Characteristic 
Sink Curront 
(mA) 


7438 
I.OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I.OC 
16 


7409 
NI.OC 
16 


7408 
NI 
16 


7403 
I.OC 
16 


7400 
I 
16 


Ports 1 and 4 have 20 mA totem-pole 
bidirectional 
drivers and 1 kOterminators. 


'200 


-=*~----"":~.---- .... 
L;S8C!101 
OPTION 


Driver 
Characteristic 
Sink Current (mA) 


Data 
lri·state 
50 


Address 
lr'-state 
50 


Commands 
Tri-state 
32 


,..1I,,,.,,,,al 
",1IC1ld\,;UHI::illCS 


Width - 
12.00 in. (30.48cm) 


Height - 
6.75 in. (17.15cm) 


Depth - 
0.50 in. (1.26 cm) 


Weight - 
14 oz (397.6gm) 


Electrical 
Characteristics 
DC Power Requirements 


Voltoge 
Without 
Wlth4K 
With 
RAM 
Wlth8K 
PROM' 
PROM' 
ISBC5303 
Only4 
PROMs 


(",5%) 
(m•• ) 
(m•• ) 
(max) 
(max) 
(m•• ) 


vcc: 
+ 5V 
IcC:4.0A 
4.9A 
4.9A 
1.1A 
5.2A 


Voo: 
+ 12V 
loo:90mA 
350 mA 
450 mA 
- 
90 mA 


Vaa: 
- 5V 
laa: 
2 mA 
,80mA 
'80 
mA 
- 
2mA 


v •• 
: 
-12V 
t •• 
:20mA 
20 mA 
'20 
mA 
- 
20 mA 


Notes 


1. Does not include 
power required tor optional 
PROM, 110drivers, and 


If0 terminators. 


2. With four 2708 EPROMs and 2200/3300 
input terminators 
installed 
for 


32 110lines, all terminator 
Inputs low. 


3. With 
tour 2708 EPROMs, 
2200/3300 
input 
terminators 
installed 
for 32 


110lines, all terminator inputs low, and iSBC 530 Teletypewriter 
Adapter 


drawing power from serial port connector. 


4 
RAM chips powered via auxilIary power bus. 


S. With four 8716 EPRQMs and eight 2200/3300 
input terminators 
in· 
stalled, all termmator inputs low. 


Environmental 
Characteristics 
Operating Temperature - 
O"C to 55"CC 


Reference Manual 
98003170 - 
iSBC 80/20-5 Hardware Reference Manual 


(NOT SUPPLIED) 
Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California 95051. 


Part Number 


SBC 80/20-4 


Description 


Single Board Computer with 4K bytes 
RAM 


I~D\""-" 
OUI 
I g 
SINGLE 
BOARD 
COMPUTER 


• Two iSBX™ bus connectors 
for iSBX™ 
MUL TIMODULE™ 
board expansion 
• Programmable 
synchronousl 


asynchronous 
communications 
interface 
with RS232C 
compatibility 


• Six 28-pin 
JEDEC 
compatible 
sockets 
for RAM/EPROM/E 


2PROM 
hold up to 
64KB of memory 


• Single level interrupt with 1 2 interrupt 


sources 


• 2K x 8 static RAM in one of the six 
JEDEC 
sockets 


The Intel@iSBC® 80/16 board is a member of Intel's complete line of OEM microcomputer systems which take 
full advantage of Intel's LSI technology to provide economical, self-contained 
computer-based 
solutions for 


OEM applications. The iSBC 80/16 board is a complete computer system on a single 6.75 x 12.00-inch printed 
circuit 
card. The CPU, system clock, iSBX bus interface, read/write 
memory, memory sockets, I/O ports and 


drivers, and serial communications 
interface all reside on the board. MULTIBUS control logic is included to offer 


compatibility 
with the Intel OEM Microcomputer 
Systems family of memory expansion boards, and peripheral 


and communication controllers. 


The following 
are trademarks 
01 Intel Corporation 
and its affiliates 
and may be used only 10 Idenlily 
Inlel products 
Intel, Inlellec, 
ICE, jRMX, 
iSBC, iSBX, iSXM. 
MUl TIBUS, 


MUL TIMODULE, 
Multichannel, 
ieS. and iPOS 
Intel Corporation 
Assumes 
No ResponsIbility 
lor the use 01 Any Circuitry 
Other Than Circuitry 
Embodied 
in an Intel Product. 
No 
Other Palei'll LIcenses afe Implied 
JULY 1982 


ClINTEl 
CORPORATION, 
1982 
3-121 
Order Number: 210503·001 


Intel's 8-bit n-channel 
MOS 8080A CPU, fabricated 


on a single LSI chip, is the central processor for the 
iSSC 80/16 
board. 
The 8080A 
contains 
six 8-bit 


general purpose registers and an accumulator. 
The 


six general purpose registers may be addressed indi- 
vidually or in pairs, providing both single and double 
precision operators. A block diagram of iSBC 80/16 
board functional components is shown in Figure 1. 


iSBX™ MUL TIMODULE™ On-Board 
Expansion 


Two 8-bit 
iSSX 
MUL TIMODULE 
connectors 
are 


provided on the iSBC 80/16 microcomputer. Through 
these connectors, 
additional 
on-board I/O functions 


may be added. 
iSBX 
MUL TIMODULES 
optimally 


support 
functions 
provided 
by VLSI peripheral 


components 
such as additional 
parallel and serial 


I/O, 
analog 
I/O, 
small 
mass 
storage 
device 


controllers 
(e.g., cassettes 
and floppy disks), 
and 


other custom interfaces 
to meet specific 
needs. By 


mounting directly on the single board computer, less 
interface logic, less power, simpler packaging, higher 
performance, and lower cost result when compared 
to other alternatives 
such as MULTIBUS form factor 


compatible boards. The iSBX connectors on the iSBC 
80/16 
board 
provide 
all 
signals 
necessary 
to 
interface to the local on-board bus. A broad range of 
iSBX MULTIMODULE options 
are available 
in this 


family from Intel. Custom iSBX modules may also be 
designed for use on the iSBC 80/16 board. An iSBX 
bus interface specification 
is available from Intel. 


The 8080A 
has a 16-bit 
program 
counter 
which 
allows 
direct 
addressing 
of up to 64K bytes 
of 
memory. 
An external 
stack, 
located 
within 
any 
portion 
of read/write 
memory, 
may be used as a 
last-in/first-out 
storage area for the contents of the 


program counter, flags, accumulator, 
and all of the 
six general purpose registers. A 16-bit stack pointer 
controls 
the addressing 
of this external stack. This 


stack provides subroutine 
nesting bounded only by 
memory size. 


The iSSC 80/16 
board 
contains 
six 28-pin 
com- 
patible 
byte 
wide 
memory 
sockets. 
These 
are 
compatible 
with 
2K x 8 (Intel 2716), 4K x 8 (Intel 
2732), 
8K x 8 (Intel 
2764), 
and 
16K x 8 (Intel 


27128) 
EPROMs, 2K x 8 and 8K x 8 static 
RAMs, 
and 2K x 8 (Intel 2817, 2817 A) E2PROMs. Modifi- 
cation 
of the address 
decode 
PROM allows 
com- 
patibility 
with 
1K x 8 (Intel 
2708) 
EPROMs and 


future 
32K x 8 EPROMs. The sockets 
are confi- 
gured in three sets of two. Each pair may be confi- 
gured 
for similar 
devices 
which 
may be EPROM, 


RAM or PPROM 
devices. 
Using 
8K 
x 8 static 
RAMs, a maximum of 32K bytes of RAM can be in- 
stalled 
on the 
iSBC 80/16 
board. 
Using 
16 x 8 
EPROMs 
(27128s), 
a maximum 
of 64K 
bytes 
of 
EPROM can be installed 
on-board. 
In this instance 
the on-board 
RAM would then overlay the EPROM 
since 
the 
maximum 
address 
space 
of the iSBC 


80/16 
board 
is 64K bytes. All on-board 
RAM and 


EPROM 
operations 
are 
performed 
at maximum 


processor speed. 


The iSBC 80/16 
board contains 
48 programrnable 


parallel I/O lines using two Intel 8255A programmable 
peripheral interfaces. The system software is used to 
configure the I/O lines in any combination of unidirec- 
tional input/output, and bi-directional ports as indicat- 
ed in Table 1. Therefore, the I/O interface may be cus- 
tomized to meet specific peripheral requirements. In 
order to take full advantage of the large number of 
possible I/O configurations, sockets are provided for in- 
terchangeable I/O line drivers and terminators. Hence, 
the flexibility of the I/O interface is further enhanced by 
selecting the appropriate combination of optional line 
drivers and terminators to provide the required sink 
current, polarity, and drive/termination 
characteristics 


for each application. The 48 programmable I/O lines 
and signal ground lines are brought out to two 50-pin 
edge connectors 
that mate with flat cable or round 


cable. 


A programmable communications 
interface using the 


Intel® 8251 A Universal Synchronous/ 
Asynchronous 


Receiver/Transmitter 
(USART) is contained 
on the 


board. 
A 
jumper 
selectable 
baud 
rate 
generator 


Mode 
01 Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched 
& 
Latched 
Latched 
& 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
8 
X 
X 
X' 


4 
8 
X 
X 


5 
8 
X 
X 


6 
4 
X 
X 


4 
X 
X 


Notes 


Port 3 must be used as a control port when either port 1 or port 2 are used as latched and strobed input or a latched and strobed 
output port or port 1 is used as a bidirectional port. 


intel' 


provides the USART with most common communi- 
cations 
frequencies. 
The 
USART 
can 
be 
pro- 


grammed 
by the system 
software 
to select 
the 


desired synchronous 
or asynchronous 
serial data 
transmission 
technique 
(including 
IBM Bi-Sync). 


The 
mode 
of 
operation 
(i.e. 
synchronous 
or 


asynchronous), 
data 
format, 
·control 
character 


format 
and parity 
are all under 
program 
control. 


The 8251 A provides 
full duplex, 
double-buffered 


transmit 
and receive 
capability. 
Parity, 
overrun, 
and framing error detection 
are all incorporated 
in 


the USART. The compatible 
interface 
provides 
a 


direct 
interface 
to 
CRTs, 
RS232C 
compatible 


cassettes, 
and 
asynchronous 
and 
synchronous 


modems. 
The RS232C 
control 
lines, 
serial 
data 


lines, and signal ground lines are brought out to a 
26-pin 
edge connector 
that mates with 
RS232C 


compatible 
flat or round cable. 


Interrupt 
requests 
may originate from 12 sources. 


Two jumper 
selectable 
interrupt 
requests can be 


automatically 
generated 
by the 
programmable 


peripheral 
interface when a byte of information 
is 


ready to be transferred to the CPU (j.e., input buffer is 
full) or a byte of information has been transferred to a 
peripheral device (i.e., output buffer is empty). Three 
jumper 
selectable 
interrupt 
requests 
can 
be 


automatically 
generated 
by the USART when a 


character is ready to be transferred to the CPU (j.e., 
receive channel buffer is full), a character is ready to 
be transmitted 
(j.e., the USART is ready to accept a 


character from the CPU), or when the transmitter is 
empty (j.e., the USART has no character.to transmit). 
Two 
interrupt 
request 
lines 
may be interfaced 


directly to user designated 
peripheral devices; one 


via the MULTIBUS system bus and the other via the 
110 edge connector. One jumper selectable interrupt 
request 
may originate from the interval timer. Two 


general 
purpose 
interrupt 
requests 
are jumper 


selectable 
from each 
iSBX interface. 
These 
two 


signals permit a user installed iSBX board to interrupt 
the 8080A CPU. The 12 interrupt request lines share 
a si ngle CPU interrupt 
level. 
When an interrupt 


request is recognized, a restart instruction (RST 7) is 
generated. The processor responds by suspending 
program 
execution 
and executing 
a user defined 


interrupt service rOL!tineoriginating at location 38H. 


A 1.04 or 10.4 millisecond timer is available for inter- 
val interrupts or as a clock output to the parallel I/O 
connector and is jumper selectable. The timer output 
is jumper 
selectable 
to the programmable parallel 
interface, the parallel I/O connector (J1), or directly 
to the 8080A CPU. 


MUL TIBUS® 
System 
Expansion 


Capabilities 


Memory and I/O capacity 
may be expanded 
and 


additional 
functions 
added using Intel MUL TIBUS 


system compatible expansion boards. Memory may 
be expanded to 65,536 bytes by adding user speci- 
fied combinations of RAM boards, EPROM boards, or 
combination 
boards. Input/output 
capacity 
may be 


increased by adding digital 110 and analog I/O expan- 
sion boards. In addition, the iSBC 80/16 board per- 
forms as a limited bus master in that it must occupy 
the lowest priority when used with other MULTIBUS 
masters. 
The bus master may take control of the 


MULTIBUS system bus by halting the iSBC 80/16 
board 
program execution. 
Mass storage capability 


may be achieved by adding single density diskette, 
double 
density 
diskette, 
or hard disk controllers. 


Modular expandable backplanes and cardcages are 
available to support multiboard systems. 


The iRMX 80 executive, which contains all major real- 
time 
facilities 
including 
priority-based 
system 


resource 
allocation, 
intertask 
communication 
and 


control, 
interrupt 
driven 
control 
for standard 
I/O 


devices, and interrupt handling, occupies 2K bytes of 
memory which can be stored on-board 
in EPROM. 


Optional 
linkable 
and 
relocatable 
modules 
for 


console control (CRT or TTY), disk file system, and 
analog subsystems are provided with the iRMX 80 
package. User configurability 
is aided on the Intellec 


microcomputer development system by the Interac- 
tive Configuration 
Utility program provided with the 


iRMX 80 package. 


The development 
cycle of iSBC 80/16-based 
pro- 


ducts 
may be significantly 
reduced 
using Intel's 


system 
development 
tools 
available 
today. 
For 


those 
not 
requiring 
hardware 
emulation 


capabilitY,lntel 
provides 
a new 
low cost 
micro- 


computer 
development 
system. The iPDS, Person- 


al Development 
System, provides 
low cost system 


development 
for the iSBC 80/16 
board, while 
at 


the same time providing 
personal computer 
capa- 


bility for the engineer. The Intellec Series II family 
of compatible 
microcomputer 
development 
sys- 


tems 
provides 
a range 
of capability 
from 
a low 


cost disk-based 
edit debug workstation 
to a high 


performance, 
fully 
compatible 
hard-disk-based 


software development 
system. A unique in-circuit 


emulator 
(ICE-80) 
option 
provides 
the capability 


of developing 
and debugging 
software 
directly 
on 


the iSBC 80/16 board. 


Pl/M-80 
- 
Intel's 
high 
level 
programming 


language, 
PLlM, is available 
as a resident compil- 


er on Intel's 
line of development 
systems. 
PL/M 


provides the capability 
to program in a natural, al- 
gorithmic 
language 
and 
eliminates 
the 
need to 


manage register 
usage or allocate 
memory. PLIM 


programs 
can be written 
in a much shorter 
time 


than 
assembly 
language 
programs 
for 
a given 


application. 


FORTRAN 
80 
- 
For applications 
requiring 
com- 
putational 
and 
formatted 
I/O 
capabilities, 
the 


ANSI 
77 standard 
high 
level FORTRAN 80 pro- 
gramming 
language 
is 
available 
as 
a resident 


compiler 
on Intel's 
line of development 
systems. 


The 
FORTRAN 
compiler 
produces 
relocatable 


object code that may be easily linked with PLIM or 
assembly 
language 
program modules. In addition, 
the iSBC 801 FORTRAN 80 run-time 
package is a 


complete, 
ready-to-use 
set 
of 
linkable 
object 
modules which 
are fully compatible 
with iRMX 80 


systems. 
The modules, 
when combined 
with the 


FORTRAN 80 coded 
application, 
provide 
the ap- 


propriate 
interfaces 
to the disk 
file and terminal 


I/O of iRMX 80, and to the iSBX 332 math module 
for applications 
requiring 
high speed math. 


BASIC-80 
- 
A high level language 
interpreter 
is 


available 
with 
extended 
disk 
capabilities 
which 


operates 
under the iRMX 80 Real-Time 
Multitask- 


ing 
Executive 
and 
translates 
BASIC-80 
source 


programs 
into an internally 
executable 
form. This 


language 
interpreter, 
provided 
as a set of linkable 


object 
modules, 
is ideally 
suited to the OEM who 


requires 
a pass through 
programming 
language. 


The BASIC-80 
programs 
may be created, 
stored, 


and 
interpreted 
on the iSBC 80 based 
systems 


using the iSBC 802 BASIC-80 
Configurable 
iRMX 


80 
Disk-Based 
Interpreter. 
The 
iSBC 
802 
in- 


terpreter 
has a complete 
ready-to-use 
set of linka- 


ble 
object 
modules 
which 
are fully 
compatible 


with 
Intel's 
iRMX 80 Real-Time 
Multitasking 
Ex- 


ecutive 
Software. 
The modules 
provide interfaces 


to disk 
file 
and 
terminal 
I/O, 
software 
floating 


point, 
or interface 
to other 
routines 
provided 
by 


the user. 


Instruction 
- 
8, 16, or 24 bits 
Data - 
8 bits 


Basic Instruction Cycle - 
1.95 usec, 2.048 MHz 
Note: Basic instruction cycle is defined as the fastest instrucHon (i.e.• four 
clock 
cycles). 


0-1 FFF using 2716' (8KB) 
0-3FFF using 2732 (16KB) 
0-7FFF using 2764 (32KB) 
O-bottom of RAM using 27128 (64KB minus on- 
board RAM) 


3000-3FFF(4KB),3800-3FFFinstalled' (2KB)with 2716 
4000-4FFF(4KB)with 2732 
X(XX)..FFFF(4KB,16KBor 32KB)with 2764 or 27128 


64K bytes (sockets only) 
May be added in 2K (using Intel 2716), 4K (using 
Intel 2732), 8K (using Intel 2764), or 16K (using Intel 
27128) byte increments. 
May be added in 1K byte 


(using 
Intel 
2708) 
increments 
if decode 
prom 
is 


reprogram med. 


2K bytes in one of the six JEDEC sockets. 
Expan- 


sion to a maximum of 32K bytes using 8Kx8 static 
RAMs in four sockets. 


Up to 64K bytes 
using 
user specified 
combina- 


tions of RAM, ROM, EPROM, and E2PROM. 


Device 
I/O 
Address 


8255A 
NO.1 
PortA 
E4 


Port B 
E5 


PortC 
E6 


Control 
E7 


8255A 
NO.2 
PortA 
E8 


Port B 
E9 


PortC 
EA 


Conlrol 
EB 


8251A 


Data 
EC 


Control 
ED 


iSBX™ 
Mullimodule™ 
J5 
MCSO 
FO-F7 
MCS1 
F8-FF 


iSBX™ 
Multimodule™ 
J4 


MCSO 
CO-C7 
MCS1 
C8-CF 


Parallel - 48 programmable 
lines 


Serial- 
1 transmit, 
1 receive 


MUL TIMODULE - 2 iSBX MULTIMODULE Boards 


Frequency 
(kHz) 
Baud 
Rate 
(Hz) 


(Jumper 
Selectable) 
Synchronous 
Asynchronous 


Program 
Selectable) 


16 
64 
307.2 
- 
19200 
4800 
153.6 
- 
9600 
2400 
76.8 
- 
4800 
1200 


38.4 
38400 
2400 
600 


19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


460.8 
- 
- 
7200 
230.4 
- 
14400 
3600 
115.2 
- 
7200 
1800 
57.6 
- 
3600 
900 


28.8 
28800 
1800 
450 


14.4 
14400 
900 
225 


7.2 
7200 
450 
112.5 


Synchronous 
- 5-8 bit characters; 
internal 
or ex- 


ternal character 
synchronization; 
automatic 
sync 


insertion. 


Asynchronous 
- 5-8 bit characters; 
break charac- 


ter generation; 
1, 1-1/2, 
or 2 stop bits; false start 


bit detectors. 


Single-level 
with on-board 
logic that automatically 


vectors the processor 
to location 
38H using a res- 


tart 
instruction 
(RST 7). Interrupt 
requests 
may 


originate 
from 
user 
specified 
I/O 
(2); the 
pro- 


grammable 
peripheral 
interface 
(2); two from each 


iSBX MULTIMODULE 
board 
(4); the programma- 


ble communications 
interface 
(3); or the interval 


timer (1). 


Voltage 
Without 
EPROM 


VCC ~ 
+5V 
±5% 
ICC ~ 
1.95A 


Voo - 
+12V 
±5% 
IOO-160mA 


VBB 
~ -5V ±5% 
IBB ~ 0 


VAA ~ -12V 
±5% 
IAA ~ 
100mA 


Notes: 
1. Does not include power required for byte-wide memory devices, 110 


drivers, or 110 terminators. 


2. 
Max lee for memory devices is 420 mA 


3. 
VSS only required for 2708s. 


MULTIBUS - All signals TTL compatible 
iSBX Bus - All signals TTL compatible 
Parallel I/O - All signals TTL compatible 
Serial I/O - RS232C interface 
Interrupt Requests - All TTL compatible 
(active-low) 


Interval Timer - 1.042 msec ±0.1 % 


or 10.42 msec ±0.1 % 
with interrupt 
latch 


Double- 
Interface 
Sided 
Centers 
Mating 
Connectors· 
Pins (qty.) 
On.) 


MULTIBUS~ 
86 
0.156 
ELFAB 
BS1562043PBB 


System 
Viking 
2KH43/9AMK12 
Bus 
Soldered 
PCB Mount 
EDAC 337086540201 
ELFAB 
BW1562D43PBB 


EDAC 337086540202 
ELF AB BW 1562A43PBB 


Wire Wrap 
Auxiliary 
60 
0.100 
EDAC 345060524802 
Bus 
ELFAB 
BS1 020A30PBB 


EDAC 345060540201 
ELFAB 
BW1 020D30PBB 


Wire Wrap 
iSBX™ 
Bus 
36 
0.100 
Viking 
VSBX 000292-0001 


(2) 


Parallel 
1/0 
50 
0.100 
3M3415-001 
Flat Crimp 
(2) 
GTE Sylvania 


6AD01251A1DD 
Soldered 
Serial 
1/0 
26 
0100 
AMP 15837151 


EDAC 345026520202 


PCB Soldered 


3M 3462-0001 
AMP 88373-5 
Flat Crimp 


Width - 12.00 in. (30.48 cm) 
Height - 6.75 in. (17.15 cm) 
Depth - 0.5 in.(1.27 
cm) 
Weight - 13 oz. (371 gm) 


I/O Drivers 
- The following 
line drivers 
and ter- 


minator.s are all compatible 
with 
the 
I/O 
driver 


sockets on the iSBC 80/16 board: 


Driver 
Characteristic 
Sink 
Current 
(mA) 


7438 
I.OC 
48 
7437 
I 
48 
7432 
NI 
16 
7426 
I,OC 
16 
7409 
NI.OC 
16 
7408 
NI 
16 


7403 
I.OC 
16 
7400 
I 
16 


. Port 1 has 25 mA totem pole drivers and 1 kD 


terminators. 
110 Terminators - 220D/330D 
divider or 1 kD pull up. 


+5;: 
220<1 
L 


22011/330 
II 
----- 
isac 901 OPTION 


330 II 


Function 
Characteristic 
Sink 
Current 
(mA) 


Data 
Trl-State 
32 
Address 
Tri-State 
24 
Commands 
Tri-State 
32 


Operating Temperature 
- O°C to 55°C 


Relative Humidity - to 90%, non-condensing 


iSBC 80/16 Single Board Computer 
iSBC 80/16 Schematic 


9803119-01 
- iSBC 80/16 
Single Board Computer 


Hardware Reference Manual 


(NOT SUPPLIED). 


Manuals 
may be ordered 
from 
any 
Intel 
sales 


representative. 
distributor 
office or from Intel lit- 


erature 
Department, 
3065 Bowers Avenue. Santa 


Clara, California. 
95051. 


Part Number 
SBC80/16 
Description 
Single Board Computer 


iSBcn~80/10B (or pSBC 80/10B*) 
SINGLE 
BOARD COMPUTER 


• Upward compatible with iSBC™ 80/10A 
Single Board Computer 


• 8080A CPU used as central processing 
unit 
. 


• One iSB)(TMbus connector for iSB)(TM 
MULTIMODULE'M board expansion 


• 1K byte of read/write memory with 
sockets for expansion up to 4K bytes 


• Sockets for up to 16K bytes of read 
only memory 


• 48 programmable parallel I/O lines 
with sockets for interchangeable 
line 
drivers and terminators 


• Programmable synchronous/asynchro- 
nous communications 
interface with 


selectable RS232C or teletypewriter 
compatibility 


• Single level interrupt with 11 interrupt 
sources 


• Auxiliary power bus and power-fail 


interrupt control logic for RAM battery 
backup 


The Intel® iSBC 80/10B board is a member of Intel's complete 
line of OEM microcomputer 
systems which 
take full 
advantage 
of Intel's 
LSI technology 
to provide 
economical, 
self-contained 
computer-based 


solutions 
for OEM applications. 
The iSBC 80/10B board is a complete computer system on a single 6.75 x 


12.00-inch printed circuit 
card. The CPU, system clock, iSBX bus interface, read/write 
memory, read only 


memory sockets, I/O ports and drivers, serial communications 
interface, bus control 
logic, and drivers all 


reside on the board. 


FUNCTIONAL 
DESCRIPTION 


Intel's powerful 
8-bit n-channel 
MOS 8080A CPU, 


fabricated 
on 
a single 
LSI chip, 
is the 
central 
processor 
for the iS8C 
80/108 
board. The 8080A 
contains 
six 8-bit general purpose registers and an 
accumulator. 
The six general 
purpose 
registers 
may be addressed individually 
or in pairs, providing 
both single and double precision operators. A block 
diagram 
of iS8C 80/108 
board functional 
compo- 
nents is shown 
in Figure 
1. 


ISBX Bus MULTIMODULE 
Board 
Expansion 


The new iS8X bus interface 
brings an entirely 
new 


dimension 
to system 
design 
offering 
incremental 


on-board 
expansion 
with small iS8X boards. One 


iS8X 
bus 
connector 
interface 
is provided 
to 


accomplish 
plug-in 
expansion 
with 
any 
iS8X 


MUL TIMODULE 
board. iS8X boards are available 


to provide expansion 
equivalent to the I/O available 


on the iS8C 80/108 board or the user may configure 
entirely 
new functionality 
such as math directly 
on- 


board. 
The 
iS8X 
350 programmable 
I/O 
MUL TI- 


MODULE 
board 
provides 
24 I/O 
lines 
using 
an 


8255A programmable 
peripheral 
interface. 
There- 


fore, the iS8X 350 module together 
with the iS8C 


80/108 
board may offer 72 lines of programmable 


I/O. Alternately, 
a serial port may be added using 


the iS8X 351 serial I/O multimodule 
board or math 


may be configured 
on-board 
with 
the iS8X 
332 


floating 
point 
math MUL TIMODULE 
board. 


BAUD RATE 
SELECTOR 
(JUMPERS) 


16K I: 8 
ROM/EPROM 
(SOCKETS) 


1K J: 8 RAM 


(SOCKETS 
TO 


4K 
J. 
8) 


PROGRAMMABLE 


COMMUNICATIONS 
INTERFACE 
(USART) 


1---- 
- 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
IL 
_ 


The iSBX board 
is a logical 
extension 
of the on- 


board 
programmable 
I/O and is accessed 
by the 


iSBC 
80/10B 
single 
board 
computer 
as common 


I/O 
port 
locations. 
The 
iSBX 
board 
is coupled 


directly 
to the 8080A CPU and therefore 
becomes 


an integral element of the iSBC 80/10B single board 
computer 
providing 
optimum 
performance. 


Memory Addressing 


The 8080A 
has a 16-bit 
program 
counter 
which 


allows 
direct 
addressing 
of up to 64K bytes 
of 


memory. 
An external 
stack, 
located 
within 
any 


portion 
of read/write 
memory, 
may be used as a 


last-in/fi rst-out storage area for the contents 
of the 


program 
counter, 
flags, accumulator, 
and all of the 


six general purpose registers. A 16-bit stack pointer 
controls 
the addressing 
of this external stack. This 


stack provides subroutine 
nesting bounded only by 


memory 
size. 


Memory Capacity 


The 
iSBC 
80/10B 
board 
contains 
1K bytes 
of 


read/write 
static 
memory. 
In addition, 
sockets 
for 


up to 4K bytes of RAM memory 
are provided 
on 


board. 
Read/write 
memory 
may be added 
in 1K 


byte 
increments 
using 
two 
1Kx4 
Intel 
2114A-5 
static 
RAMs. 
All 
on-board 
RAM read and write 
operations 
are performed 
at maximum 
processor 


speed. Sockets 
for up to 16K bytes of nonvolatile 


read-only-memory 
are 
provided 
on 
the 
board. 
Read-only-memory 
may be added 
in 1K byte 
in- 
crements 
up to 4K bytes (using Intel 2708 or 2758); 
in 2K byte increments 
up to 8K bytes (using 
Intel 


2716); or in 4K byte increments 
up to 16K bytes (us- 


ing Intel 2732). All on-board 
ROM or EPROM read 
operations 
are performed 
at maximum 
processor 
speed. 


Parallel I/O Interface 


The iSBC 80/10B board contains 
48 programmable 
parallel 
I/O 
lines 
implemented 
using 
two 
Intel 


8255A programmable 
peripheral 
interfaces. 
The 


system software is used to configure 
the I/O lines in 
any combination 
of unidirectional 
input/output, 


and bidirectional 
ports indicated 
in Table 1. There- 


fore, the I/O interface 
may be customized 
to meet 


specific 
peripheral 
requirements. 
In order 
to take 


full advantage 
of the large number of possible 
I/O 
configurations, 
sockets 
are 
provided 
for 
inter- 


changeable 
I/O line drivers and terminators. 
Hence, 


the flexibility 
of the I/O interface is further enhanced 
by the 
capability 
of selecting 
the appropriate 


combination 
of optional 
line drivers and terminators 
to provide 
the required 
sink current, 
pOlarity, and 


drive/termination 
characteristics 
for each appli- 
cation. 
The 48 programmable 
I/O lines and signal 
ground 
lines are brought 
out to two 50-pin 
edge 
connectors 
that mate with flat cable or round cable. 


A programmable 
communications 
interface 
using 


the 
Intel® 
8251A 
Universal 
Synchronous/Asyn- 
chronous 
Receiver/Transmitter 
(USART) 
is con- 
tained on the board. A jumper selectable 
baud rate 


generator 
provides 
the 
USART 
with 
all common 
communications 
frequencies. 
The USART can be 


Mode 
01 Operation 


Unidirectional 


Port 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched 
& 
Latched 
Latched 
& 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
8 
X 
X 
X' 


4 
8 
X 
X 


5 
8 
X 
X 


6 
4 
X 
X 


4 
X 
X 


Notes 


Port 3 must 
be used as a control 
port when 
either 
port 1 or port 2 are used as a latched 
and strobed 
input 
or a latched 
and strobed 
output 
port or port 
1 is used as a bidirectional 
port. 


programmed 
by the system software 
to select the 
desired 
synchronous 
or asynchronous 
serial data 
transmission 
technique 
(including 
IBM 
Bi-Sync). 


The mode of operation 
(i.e., synchronous 
or asyn- 
chronous), 
data format, 
control 
character 
format 
and parity are all under program control. 
The 8251A 
provides 
full duplex, 
double-buffered 
transmit 
and 
receive 
capability. 
Parity, 
overrun, 
and framing 
error detection 
are all incorporated 
in the USART. 
The inclusion 
of jumper selectable 
TTY or RS232C 
compatible 
interfaces 
on the board, in conjunction 
with 
the 
USART, 
provides 
a direct 
inlerface 
to 
teletypes, CRTs, RS232C compatible 
cassettes, and 
asynchronous 
and synchronous 
modems. 
The 
RS232C or TTY command 
lines, serial data lines 
and signal ground 
lines are brought 
out to a 26-Pi~ 
edge connector 
that mates with 
RS232C compat- 
ible flat or round 
cable. 


Interrupt Capability 


Interrupt 
requests 
may originate 
from 
11 sources. 
Two jumper 
selectable 
interrupt 
requests 
can be 
automatically 
generated 
by the programmable 
peripheral 
interface 
when a byte of information 
is 
ready to be transferred 
to the CPU (i.e., input buffer 
is full) or a byte of information 
has been transferred 
to a peripheral 
device (i.e., output 
buffer is empty). 
Three jumper 
selectable 
interrupt 
requests can be 
automatically 
generated 
by the 
USART 
when 
a 


character 
is ready to be transferred 
to the CPU (i.e., 
receive channel 
buffer is full), a character 
is ready 
to be transmitted 
(i.e., the USART is ready to accept 


a character 
from the CPU), or when the transmitter 


is empty 
(i.e., 
the 
USART 
has no character 
to 


transmit). 
These five interrupt 
request lines are all 
maskable 
under 
program 
control. 
Two interrupt 


request 
lines 
may 
be interfaced 
directly 
to 
user 
designated 
peripheral 
devices; one via the MUL TI- 
BUS system 
bus and the other 
via the 
I/O edge 
connector. 
One jumper 
selectable 
interrupt 
request 
may 
be 
interfaced 
to the 
power-fail 
interrupt 


control 
logic. 
One jumper 
selectable 
interrupt 
request may originated 
from the interval timer. Two 
general 
purpose 
interrupt 
requests 
are jumper 


selectable 
from 
the 
iSBX 
interface. 
These 
two 


signals 
permit 
a user 
installed 
MUL TIMODULE 
board 
to 
interrupt 
the 
8080A 
CPU. 
The 
eleven 
interrupt 
request lines share a single CPU interrupt 
level. When 
an interrupt 
request 
is recognized, 
a 


restart 
instruction 
(RESTART 
7) is generated. 
The 
processor 
responds by suspending 
program execu- 


tion and executing 
a user defined 
interrupt 
service 


routine 
originating 
at location 
3816. 


Power-Fail Control 


A power-fail 
interrupt 
may be detected through 
the 
AC-Iow signal generated 
by the power supply. This 


signal 
may be configured 
to interrupt 
the 8080A 


CPU to initiate 
an orderly 
power down instruction 


sequence. 


A 1.04 millisecond 
timer 
is available 
for 
interval 


interrupts 
or as a clock 
output 
to the parallel 
I/O 


connector. 
The timer output 
is jumper selectable 
to 


the 
programmable 
parallel 
interface, 
the 
parallel 


I/O connector 
(J1), or directly 
to the 8080A CPU. 


MULTIBUS®System 
Expansion Capabilities 


Memory 
and I/O 
capacity 
may be expanded 
and 


additional 
functions 
added using Intel MUL TIBUS'· 


system compatible 
expansion 
boards. Memory may 


be expanded 
to 65,536 bytes by adding 
user speci- 


fied combinations 
of RAM boards, EPROM boards, 


or combination 
boards. Input/output 
capacity 
may 


be increased 
by adding 
digital 
I/O and analog 
I/O 


expansion 
boards. 
In addition, 
the 
iSBC 
80/10B 


board 
performs 
as a limited 
bus master 
in that 
it 


must 
occupy 
the lowest 
priority 
when 
used with 


other 
MUL TIBUS 
masters. 
The bus master 
may 


take control 
of the MUL TIBUS system bus by halt- 


ing the iSBC 80/10B board program execution. Mass 
storage capability 
may be achieved by adding single 


density 
diskette, 
double 
density 
diskette, 
or hard 


disk 
controllers. 
Modular 
expandable 
backplanes 


and cardcages 
are available to support 
multiboard 


systems. 


Real-Time Software 


The iRMX 80 executive, 
which 
contains 
all major 


real-time 
facilities 
including 
priority-based 
system 


resource 
allocation, 
intertask 
communication 
and 


control, 
interrupt 
driven 
control 
for standard 
I/O 


devices, and interrupt 
handling, 
occupies 
2K bytes 


of 
memory 
which 
can 
be 
stored 
on-board 
in 


EPROM. 
Optional 
linkable 
and 
relocatable 


modules 
for console 
control 
(CRT or TTY), disk file 


system, 
and analog subsystems 
are provided 
with 


the iRMX 80 package. User configurability 
is aided 


on 
the 
Intellec 
microcomputer 
development 


system 
by the Interactive 
Configuration 
Utility 
pro- 


gram provided 
with the iRMX 80 package. 


System Development Capability 


The development 
cycle of iSSC 80/10S-based 
pro- 


ducts 
may be signfficantly 
reduced 
using 
Intel's 


system 
development 
tools 
available 
today. 
For 


those not requiring 
hardware 
emulation 
capability, 


Intel 
provides 
a new 
low 
cost 
microcomputer 


development 
system. The iPDS, Personal Develop- 


ment System, 
provides 
low cost system 
develop- 


ment for the iSBC 80/10B board, while at the same 
time providing 
personal 
computer 
capability 
for the 


engineer. 
The Intellec Series II family of compatible 


microcomputer 
development 
systems 
provides 
a 


range of capability 
from a low cost disk-based 
edit 


debug 
workstation 
to a high 
performance, 
fully 


compatible 
hard-disk-based 
software 
development 


system. A unique in-circuit emulator (ICE-80) option 
provides the capability of developing 
and debugging 


software directly 
on the iSBC 80/10B. 


Programming Capability 


PL/M-80 
- 
Intel's 
high 
level 
programming 
lan- 


guage, PUM, is also available as a resident Intellec 
microcomputer 
development 
system 
option. 
PL/M 


provides 
the capability 
to program 
in a natural, 
algorithmic 
language 
and eliminates 
the need to 


manage 
register 
usage or allocate 
memory. 
PL/M 


programs 
can be written 
in a much shorter 
time 


than 
assembly 
language 
programs 
for 
a given 


application. 


FORTRAN-80 
- 
For applications 
requiring 
compu- 


tational 
and formatted 
I/O capabilities, 
the ANSI 77 


standard 
high 
level 
FORTRAN-80 
programming 


language 
is available 
as a resident 
option 
of the 


Intellec system. The FORTRAN compiler 
produces 


relocatable 
object 
code that may be easily 
linked 


with 
PUM 
or 
assembly 
language 
program 


modules. 
In addition, 
the iSBC 801 FORTRAN-80 


run-time 
package 
is a complete, 
ready-to-use 
set 


of linkable 
object 
modules 
which 
are fully 
com- 


patible with iRMX 80 systems. 
The modules, 
when 


combined 
with 
the 
FORTRAN-80 
coded 
applica- 


tion, provide the appropriate 
interfaces 
to the disk 


file and terminal 
I/O of iRMX 80, and to the iSBC 


310A 
Math 
Unit 
for 
applications 
requiring 
high 


speed math. 


BASIC·80 
- 
A high 
level language 
interpreter 
is 


available 
with 
extended 
disk 
capabilities 
which 


operates 
under the iRMX 80 Real-Time 
Multitask- 
ing Executive 
and translates 
BASIC-80 source 
pro- 


grams 
into 
an 
internally 
executable 
form. 
This 


language 
interpreter, 
provided 
as a set of linkable 


object 
modules, 
is ideally 
suited 
to the OEM who 
requires 
a pass through 
programming 
language. 


The BASIC-80 
programs 
may be created, 
stored, 


and interpreted 
on the iSBC 80 based systems 
us- 


ing the iSBC 802 BASIC-80 Configurable 
iRMX 80 


Disk-Based 
Interpreter. 
The iSBC 802 Interpreter 


has a complete 
ready-to-use 
set of linkable 
object 


modu'les 
which 
are fully 
compatible 
with 
Intel's 


iRMX 80 Real-Time 
Multitasking 
Executive 
Soft- 


ware. The modules 
provide 
interfaces 
to disk file 


and terminal 
I/O, software 
floating 
point, 
or inter- 


face to other routines 
provided 
by the user. 


Word Size 
Instruction 
- 
8, 16, or 24 bits 


Data - 
8 bits 


Cycle Time 
Basic 
Instruction 
Cycle 
- 
1.95 J.lSec 
Note 
Basic instruction cycle is defined as the fastest instruction (i.e., 
four clock cycles). 


Memory Addressing 
On-Board 
ROM/EPROM 
O-OFFF using 
2708, 2758 


0-1FFF using 
2716 
0-3FFF using 
2732 


On-Board 
RAM 
3COO-3FFF with 
no RAM expansion 


3000-3FFF 
with 2114A-5 expansion 


Note 
All RAM configurations are automatically moved up to a base 
address of 4XXX when configuring EPROM for 2732. 


Memory Capacity 
On-Board 
ROM/EPROM 
16K bytes 
(sockets 
only) 


On-Board 
RAM 
1K byte with 
user expansion 
in 1K increments 


to 4K bytes using 
Intel 2114A-5 
RAMs 


Off-Board 
Expansion 
Up to 64K bytes using user specified 
combina- 


tions 
of RAM, ROM, and EPROM. 


I/O Addressing 
On-Board 
Programmable 
I/O 


Device 
I/O 
Addresl 


8255A NO.1 


Port A 
E4 


Port B 
E5 


Port C 
E6 
Control 
E7 


8255A No.2 
Port A 
E8 


Port 8 
E9 


Port C 
EA 
Control 
EB 


8251A 


Data 
EC 
Control 
ED 


iSBX MultimoduJe 


MCSO 
FO-F7 
MCS1 
F8-FF 


1/'"' ""Ut'U"'" J 
Parallel 
- 
48 programmable 
lines 


Serial - 
1 transmit, 
1 receive 
MUL TIMODULE 
- 
1 iSBX Bus MUL TIMODULE 


Board 


Baud Rate (Hz) 


, Frequency 
(kHz) 
(Jumper 
Selectable) 
Synchronous 
Asynchronous 
(Program Selectable) 


-;- 16 
-;- 64 


3072 
- 
,9200 
4800 


1536 
- 
9600 
2400 


768 
- 
4800 
,200 


38.4 
38400 
2400 
600 


19.2 
19200 
'200 
300 


9.6 
9600 
600 
150 


6.98 
6980 
- 
,,0 


4.8 
4800 
300 
75 


Serial Communications Characteristics 
Synchronous 
- 
5-8 bit characters; 
internal 
or ex- 


ternal 
character 
synchronization; 
automatic 
sync 


insertion 


Asynchronous 
- 
5-8 bit characters; 
break charac- 


ter generation; 
1, 1V2, or 2 stop bits; false start bit 
detectors 


Interrupts 
Single-level 
with on-board 
logic that automatically 
vectors 
the processor 
to location 
38H using a re- 


start instruction 
(RESTART7). 
Interrupt 
requests 


may originate 
from user specified 
1/0 (2); the pro- 


grammable 
peripheral 
interface (2); the iSBX MUL- 


TIMODULE 
board (2); the programmable 
commu- 


nications 
interface 
(3); the power fail interrupt 
(1); 
or the interval 
timer 
(1). 


MUL TIBUS 
- 
All signals 
TTL compatible 


iSBX Bus - 
All signals 
TTL compatible 


Parallel 
1/0 
- 
All signals 
TTL compatible 


Serial 1/0 - 
RS232C or a 20 mil current 
loop TTY 


interface 
(jumper 
selectable) 


Interrupt 
Requests - 
All TTL compatible 
(active- 


low) 


Clocks 


System Clock 
- 
2.048 MHz ± 0.1% 


Interval 
Timer 
- 
1.042 msec ± 0.1% (959.5 HZ) 


Double·Slded 
Centers 
Interface 
Pins 
(In.) 
Mating Connectors 


(qty) 


MULTIBUS 
86 
0.156 
Viking 2KH43/9AMK12 


System 
Wire-wrap 


iSBX Bus 
36 
0.1 
iSBX 960·5 


Parallel 110(2) 
50 
0.1 
3M 3415-000 
Flat 


Serial 1/0 
26 
0.1 
AMP 87194·6 
Flat 


Physical Characteristics 


Width 
- 
12.00 in. (30.48 cm) 


Height 
- 
6.75 in. (17.15 cm) 


Depth - 
0.05 in. (1.27 cm) 


Weight - 
14 oz. (397.3 gm) 


Voltage 
Without 
EPROM' 
With 
2708 EPROM2 


::1~~;;~8;':~:3 


Power Down Requirements 
(RAM and Support 
Circuit) 


Vcc ~ +5V ±5% 
14cc = 2.0A 
31 A 
3.46 A 
84 mA + 140 mA/K 
(2114A-5) 


Voo = +12V ±5% 
100 = 150 mA 
400 mA 
150 mA 
Not Required 


Vee = -5V 
±5% 
lee = 2 mA 
200 mA 
2 mA 
Not Required 


VAA = -12V 
±5% 
IAA = 175 mA 
175 mA 
175 mA 
Not Required 


NOTES: 


1. Does not include power required for optional ROM/EPROM. 110 drivers, or I/O terminators. 


2. With four Intel 2708 EPROMS and 2200/3300 
for terminators, Installed for 48 input lines. All terminator 
inputs low 


3. Same as #2 except with four 2758s. 2716s, or 2732s installed 


4. lee shown without RAM supply current 
For 2114A-5 add 140 mA per K byte to a maximum of 560 mA. 


Line Drivers and Terminators 
I/O Drivers - 
The following 
line drivers and termi- 


nators are all compatible 
with the I/O driver sockets 


on the iSBC 80/10B Board: 


Driver 
Characteristic 
Sink Current (mA) 


7438 
I,Oc 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,Oc 
16 


7409 
NI,Oc 
16 


7408 
NI 
16 


7403 
I,Oc 
16 


7400 
I 
16 


Note 
I - inverting, NI - non-inverting, OC - open collector. 


Port 1 has 25 nA totem pole drivers and 1 kO termi- 
nators. 
I/O Terminators 
- 
2200/3300 
divider or 1 kO pull 


up. -:~ 
220""'." J 
~~----- 
----~o 
see 
to1 OPTION 


Function 
Characteristic 
Sink Current (mA) 


Data 
Tri-State 
25 


Address 
Tri-State 
25 


Commands 
Tri-State 
25 


Environmental Characteristics 
Operating 
Temperature 
- 
O°C to 55°C 


Equipment Supplied 
iSBC 80/10B Single 
Board 
Computer 


iSBC 80/10B Schematics 


Reference Manual 
9803119-01 
- 
iSBC 80/10B Single Board Computer 


Hardware 
Reference 
Manual 
(NOT SUPPLIED). 


Manuals may be ordered from any Intel sales repre- 
sentative, distributor 
office or from Intel Literature 


Department, 
3065 Bowers 
Avenue, 
Santa 
Clara, 
California 
95051. 


Part Number 
SBC 80/10B 
Description 
Single 
Board 
Computer 


iSBC 80105 (or pSBC 80/05 *) 
SINGLE 
BOARD COMPUTER 


• 8085A CPU used as central proce$sor 


• 512 bytes of static read/write memory 


• Sockets for 4K bytes of erasable 
reprogrammable 
or masked read only 
memory 


• 22 programmable parallel I/O lines with 
sockets for interchangeable 
line drivers 
and terminators 


• Full MULTIBUS control logic allowing 
up to 16 masters to share system bus 


• TTL serial I/O interface with sockets for 


RS232C line drivers and receivers 


• Fully compatible with optional iSBC 
expansion boards and peripherals 


The iSBC 80/05Single Board Computer is a member of Intel's complete line of OEM computer systems which take full 
advantage of Intel's LSI technology to provide economical, self·contained computer·based solutions for OEM applica· 
tions. The iSBC 80/05 is a complete computer system on a single 6.75x 12.00·inch printed circuit card. The CPU, 
system clock, read/write memory, nonvolatile read only memory, 110 ports and drivers, serial interface, priority inter· 
rupt logic, programmable timer, MULTIBUS control logic, and bus expansion buffers all reside on the board. 


FUNCTIONAL 
DESCRIPTION 


Intel's powerful 8-bit n-channel 8085 CPU, fabricated on 
a single LSI chip, is the central processor for the iSSC 
80105. The B085A CPU is directly software compatible 
with the popular Intel8080A CPU.The 8085Acontains six 
8-bit general purpose registers and an accumulator. The 
six general purpose registers may be addressed indIvId- 
ually or in pairs, providing both single and double preci- 
sion operators. Minimum on-board instruction 
execu- 


tion time is 2.03 microseconds. A block diagram of iSSC 
80105 functional components is shown in Figure 1. 


Memory Addressing 


The 8085A CPU has a 16-bit program counter which 
allows direct addressing of up to 65,536 bytes of mem- 
ory. An external stack, located within any portion of 
readlwrlte memory, may be used as a last-in/first-out 
storage area for the contents of the program counter, 
flags, accumulator, and all of the six general purpose 
registers. A 16-bit stack pointer controls the addressing 
of this external stack. This stack provides subroutine 
nesting bounded only by memory size. 


Memory Capacity 


The iSSC 80105 contains 512 bytes of readlwrite memory 
using Intel's low power static RAMs. Two sockets for up 
to 4K bytes of nonvolatile read only memory are provided 
on the board. Read only memory may be added in 
2K-byte increments using Intel 2716 erasable and elec- 
trically reprogrammable ROMs (EPROMs).Optionally, if 
only 2K bytes are required, read only memory may be 
added in 1K-byte increments using Intel 2708 EPROMs. 


.Parallel 1/0 Interface 


The iSSC 80105 contains 22 programmable parallel I/O 
lines implemented using the I/O ports of the Intel 8155 
RAMIIOlTjmer. The system software 
is used to con- 


figure the 1/0 lines in any combination of unidirectional 
input or output ports as indicated in Table 1. The 1/0 in- 
terface may, therefore, be customized to meet specific 
peripheral requirements. In order to take full advantage 
of the large number of possible 
I/O configurations, 


sockets are provided for Interchangeable I/O line drivers 
and terminators. Hence the flexibility of the I/O interface 
is further enhanced by the capability of selecting the ap- 
propriate combination 
of optional line drivers and ter- 


minators to provide the required sink current, polarity, 
and driveltermination 
characteristics 
for each applica- 


tion. The 22 programmable I/O lines and signal ground 
lines are brought out to a 40-pin edge connector that 
mates with flat, woven, or round cable. 


Multimaster 
Capability 


The iSSC 8085A is a full computer on a single board with 
resources capable of supporting a great variety of OEM 
system requirements. For those applications 
requiring 
additional 
processing 
capacity 
and the 
benefits 
of 


multiprocessing 
(Le., several CPUs andlor 
controllers 


logically share systems tasks with communication 
over 


the system bus), the iSBC 80105 provides full MULTIBUS 
arbitration control logic. This control logic allows up to 
three bus masters (Le., any combination of iSBC 80105, 
iSSC 80/20-4, DMA controller, diskette controller, etc.) to 
share the system 
bus in serial (daisy-chain) priority 
fashion, and up to 16 masters may share the MULTIBUS 
with the addition of an external priority network. The 
MULTISUS arbitration 
logic 
operates 
synchronously 


with a MULTIBUS clock (provided by the iSSC 80105 or 
optionally 
connected directly to the MULTISUS clock) 


while data is transferred via a handshake between the 
master and slave modules. This allows different speed 
controllers to share resources on the same bus, and for 
transfers via the bus to proceed asynchronously. ThUS, 
transfer speed is dependent on transmitting 
and receiv- 


ing devices only. This design prevents slow master 
modules from being handicapped in their attempts to 


Mode of Operation 


Unidirectional 


Lines 
Input 
Output 
Control 
Port 
(qty) 


Unlatched 
Latched & 
Latched 
Latched & 


Strobed 
Strobed 


1 
8 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
3 
X 
X 
X1 


4 
3 
X 
X 
X2 


Notes 


1. Port 3 must be used as a control port when port 1 is used as a latched and strobed input or a latched and strobed output port. 


2. Port 4 must be used as a control port when port 2 is used as a latched and strobed input or a latched and strobed output port. 


gain control of the bus, but does not restrict the speed 
at which faster modules can transfer data via the same 
bus. The most obvious applications for the master-slave 
capabilities 
of the bus are multiprocessor 
configura- 


tions, high speed direct-memory-access (DMA) opera- 
tions and high speed peripheral control, but are by no 
means limited to these three. 


Programmable 
Timer 


The iSSG 80/05 provides a fully programmable binary 
14-bit interval timer utilizing 
the Intel 8155 RAMIIOI 


Timer. The system designer simply configures the timer 
via software to meet system requirements. Whenever a 
given time delay is needed, software commands to the 
programmable timer select the desired function. Four 
functions are available as shown in Table 2. The con- 
tents of the timer counter may be read at any time dur- 
ing system operation. 


Serial 110 Interface 


The iSSG80/05 provides serial I/O capability through the 
serial input data (SID)and serial output data (SOD)func- 
tions of the Intel 8085A GPU. These functions are con- 
trolled exculsively by software through execution of the 
8085A RIM and SIM instructions. The baud rate for the 
serial I/O interface is determined by the system time 
available for execution of serial I/O support software. 
Hence, the maximum baud rate supported by the iSSG 
80/05 
is solely dependent on the overall system real- 
time software requirements. Serial I/O signals are TIL 
compatible and sockets are provided on the board for 
optional connection of RS232Gline drivers and receivers. 


Interrupt 
Capability 


The iSSG 80/05 takes advantage of the powerful inter- 
rupt processing capability of the 8085A GPU. Interrupt 
requests are routed to the four interrupt inputs of the 
8085A GPU(i.e., TRAP, RST 7.5, RST6.5, and RST5.5 in 
order of priority, TRAP highest), and each input gener- 
ates a unique memory address (i.e., TRAP:2416, RST7.5: 
3G16, RST6.5: 3416, RST5.5: 2G16). A single 8085A jump 


Operatlon 


Timer 
out 
goes 
low 
during 
the 


second half of count. Therefore, the 
count 
loaded in the count 
length 


register should be twice the pulse 
width desired. 


Timer out will remain high until one- 
half the count has been completed, 
and go' low for the other half of the 
count. 
The count 
length 
is auto- 


matically 
reloaded 
when 
terminal 


count is reached. 


Divide by N counter. 
A repetitive 


timer out low pulse is generated and 
new timeout initiated every time ter- 
minal count is reached. 


A single low pulse is generated upon 
reaching terminal count. This func- 
tion is extremely useful for genera- 
tion of real-time clocks. 


Programmable 
pulse 


Square wave 
rate generator 


Programmable 
strobe 


instruction 
at each of these addresses then provides 


linkage to locate each interrupt service routine indepen- 
dently anywhere in memory. All interrupt inputs with the 
exception of one (TRAP) may be masked via software. 
The trap interrupt should be used for conditions such as 
power-down sequences which require immediate atten- 
tion by the 8085AGPU. 


Expansion Capabilities 


Memory and I/O capacity may be expanded and addi- 
tional functions added using Intel MULTISUS compati- 
ble expansion boards. High speed integer and floating- 
point arithmetic capabilities may be added by using the 
iSSG 310A High Speed Mathematics Unit. Memory may 
be expanded to 65,536 bytes by adding user specified 
combinations of RAM boards, EPROM boards, or com- 
bination boards. Input/output capacity may be increased 
by adding digital I/O and analog I/O expansion boards. 
Mass storage capability 
may be achieved by adding 


single or double density 
diskette 
controllers 
as sub- 


systems. 
Modular expandable 
backplanes 
and card- 
cages are available to support multiboard systems. 


Systems 
Development 
Capability 


The development cycle of iSSC 80105-basedproducts may 
be significantly reduced using Intel's system development 
tools available today. For those not requiring hardware 
emulation 
capability, 
Intel provides 
a new low cost 


microcomputer development system. The iPDS, Personal 
Development System, provideslowcostsystemdevelopment 
for the iSSC 80105 board, while at the same time providing 
personal computer capability for the engineer. The Intellec 
Series II family of compatible microcomputer development 
systems provides a range of capability from a low cost disk- 


based edit debug workstation to a high performance, fully 
compatible hard-disk-based software development system. 
A unique in-circuit emulator (ICE·85A)option provides the 
capability of developing and debugging software directly on 
the iSSC 80105 board. 


Programming 
Capability 


PUM·80 - 
Intel's 
high level programming 
language, 


PUM, is also available as a resident Intellec microcom- 
puter development 
system option. 
PUM provides the 


capability to program in a natural, algorithmic 
language 


and eliminates 
the need to manage register usage or 


allocate 
memory. PUM programs can be written 
in a 


much shorter time than assembly language programs 
for a given application. 


Word Size 
Instruction 
- 
8, 16, or 24 bits 


Data - 
8 bits 


Cycle Time 
Basic Instruction 
Cycle - 
2.03 I'S, ± 0.1% 


Note 


Basic instruction 
cycle is defined as the fastest instruction 
(Le., four 


clock 
cycles). 


Memory 
Addressing 
ROM/EPROM - 
O-'OFFFH 
RAM - 
3EOOH 


Memory 
Capacity 


On·Board ROM/EPROM - 
4K bytes (with Intel 2716) or 


2K bytes (with Intel 2708) 
On·Board RAM - 
512 bytes 
Off· Board Expansion 
- 
Up to 65,536 bytes in user 


specified combination of RAM, ROM, and PROM 


1/0 Addressing 
On·Board Programmable I/O - 
see Table 1 


Port 
8155 
8155 
8155 
8155 Timer 
8155 Timer 
8155 
Ports 
Low-Order 
Hlgh·Order 
Control 
Port 1 
Port 2 
Port 
3&4 
Byte 
Byte 


Address 
00 
01 
02 
03 
04 
05 


1/0 Capacity 
Parallel - 
22 programmable lines (see Table 1) 


Note 


The iSBC 80/05 
may be expanded 
to 1102 programmable 
input/output 


lines by using optional 
iSBC 80 110 boards. 


Serial 
Communications 
Characteristics 


SID and SOD functions 
of the 8085A CPU are used for 


serial I/O. They are controlled by software through RIM 


and SIM instructions 
of the 8085A CPU. Saud rate is 


determined by system time available for serial I/O handl· 
ing. On·board timer may be used to greatiy ease serial 
I/O timing requirements. 


Interrupts 
Four-level interrupt routed t08085A CPU interrupt inputs. 
Each interrupt automatically 
vectors the processor to a 


unique memory location. 


Interrupt 
Memory 
Priority 
Type 
Input 
Address 


TRAP 
2416 
Highest 
Non-maskable 


RST 7.5 
3C16 
~ 


Maskable 


RST 6.5 
3416 
Maskable 


RST 5.5 
2C16 
Lowest 
Maskable 


Timer 
Input Frequency Reference - 
122.88 kHz ± 0.1% (8.14 


I'S period nominal) 
Output FrequencieslTiming 
Intervals 


Function 
TlmerlCounter 


Mln 
Mox 


Programmable 
pulse 
8.14 "s 
66.67 ms 


Square wave rate generator 
7.50 Hz 
61.44 kHz 


Rate generator 
7.50 Hz 
61.44 kHz 


Programmable 
strobe 
8.14 "s 
133.33 ms 


Interfaces 
Bus - 
All signals ITL compatible 


Parallel I/O - 
All signals ITL compatible 


Interrupt Request - 
All ITL compatible (active-low) 


Serial I/O - 
ITL; 
sockets 
available for RS232C line 


drivers and receivers 


System 
Clock (808SA CPU) 


1.966MHz ± 0.1% 


Interfece 
line. 
Center. 
Mating 
Connector 


(qty) 
(In.) 


Bus 
86 double·sided 
0.156 
Viking 
2KH4319AMK12 


Parallel 
110 
50 double·sided 
0.100 
3M 341S-OOO 


Molex 
09-66·1071 
Connector 


Molex 
09·S0·7071 


se,ialllO' 


Connector 
7 single·sided 
0.156 
AMP 87194-6 
Connector 
AMP 3-8702S·4 
Connector 


Note 


1. Connectors 
and pins from one vendor 
may only be used with 
connec- 
tors and pins from the same vendor. 


Line Drivers and Terminators 
110Drivers - 
The following line drivers are all compati· 
ble with the 1/0 driver sockets on the iSBC 80/05: 


Driver 
Characteristic 
Sink Current 
(mA) 


7438 
I.OC 
48 


7437 
I 
48 
7432 
NI 
16 
7426 
I,OC 
16 
7409 
NI,OC 
16 
7408 
NI 
16 
7403 
I,OC 
16 
7400 
, 
16 


Note 


I = inverting; 
NI = non-inverting; 
OC = open collector. 


1/0 Terminators - 
Intel provides 220Q/330Q 
divider and 


1 kQ pull-up resistive terminator 
packs for termination 


of I/O lines programmed as inputs. These options are as 
follows: 


220Q 


220QI3:0;---==-;--~330; 
L 
ISBe901OPTION 


Driver 
Characteristic 
Sink Current 
(mA) 


Data 
Trl·stdte 
SO 
Address 
Trl·state 
SO 


Commands 
Tri·stc'e 
32 


RS232C Drivers and Receivers 
The following RS232Cdrivers and receivers are compati· 
ble with the RS232C socket on the iSBC 80/05: 
RS232C Driver - 
National DS1488 or TI SN75188 


RS232C Receiver - 
National DS1490 or TI SN75189 


Physical 
Characteristics 
Width - 
12.00 in. (30.49 cm) 


Height - 
6.75 in. (17.15 cm) 


Depth - 
0.50 in. (1.27 cm) 


Weight - 
12.0 oz (339.8 gm) 


Electrical 
Characteristics 
DC Power Requirements 


Voltege 
Without 
With 2718 
With 8708 


(:t5%) 
PROM1 
EPROM2 
EPROM3 


(mex) 
(mIx) 
(mIX) 


VCC= 
+ SV 
ICC= 
1.80mA 
2.6SA 
2.4SA 


VOO= 
+ 12V 4 
100=0 
7 mAS 
137 mA 


VBB= 
-SV 
4 
IBB=O 
0 
90 mA 


VAA= 
-12VS 
IAA=O 
23 mAS 
23 mAS 


Notes 


1. DoeS' not include 
power required 
for optional 
EPROM/ROM, 
110 
drivers, and 1/0 terminators. 


2. With 
two 
Intel 2716 EPROMs 
and 220Q/330Q terminators 
installed 


for 22 input ports; all terminator 
inputs low. 


3. With two Intel 2708 EPROMs and 220Q/330Q 
terminators 
installed 


for 22 input ports; all terminator 
inputs low. 


4. Required 
to, 2708 EPROMs. 


5. Required only when RS232C capability 
required. 


Environmental 
Characteristics 


Operating Temperature - 
O·C to + 55·C. 


Reference 
Manual 


98004830 - 
iSBC 80/05 
Hardware Reference Manual 


(NOT SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California 95051. 


Part Number 


SBC 80/05 


Description 


Single Board Computer 


APPLICATION 
NOTE 


A significant measure of the power and flexibility 
of the Intel OEM Computer Product Line can be 
attributed 
to the design of the Intel MULTIBUS 
system bus. The bus structure provides a common 
element 
for ·communication 
between 
a wide 
variety of system modules which include: Single 
Board Computers, 
memory, digital, 
and analog 
110 expansion boards, and peripheral controllers. 


The purpose of this application note is to help you 
develop a working knowledge ofthe Intel MULTI- 
BUS specification. 
This knowledge is essential for 
configuring 
a system 
containing 
multiple mod- 
ules. 
Another purpose is to provide you with the 
information necessary to design a bus interface for 
a slave module. One of the tools that will be used to 
achieve this goal is the complete description of a 
MULTIBUS slave design example. Other portions 
of this 
application 
note 
provide 
an in depth 
examination 
of the bus signals, operating charac- 


teristics, and bus interface circuits. 


This application 
note was originally 
written in 
1977. Since 1977, the MULTIBUS specification 
has been significantly 
expanded to cover opera- 
tion with both 8 and 16·bit system modules and 
with an auxiliary 
power bus. 
This application 
note now contains 
information 
on these 
new 
MULTIBUS specification features. 


In addition, a detailed MULTIBUS specification 
has also been published which provides the user 
with further information 
concerning MULTIBUS 
interfacing. 
The MULTIBUS specification 
and 


other useful documents are listed in the overleaf of 
this note under Related Intel Publications. 


II. MULTmUS@ SYSTEM BUS 
DESCRIPTION 


Overview 


The Intel MULTIBUS signal lines can be grouped 
in the following categories: 
20 address lines, 16 
bidirectional 
data 
lines, 8 multilevel 
interrupt 
lines, and several bus control, timing and power 
supply 
lines. 
The address 
and data 
lines are 
driven by three-state 
devices, while the interrupt 


and some other control lines are open-collector 
driven. 


Modules that use the MULTIBUS system bus have 
a master-slave relationship. 
A bus master module 


can drive the command and address lines: it can 
control the bus. 
A Single Board Computer is an 


example of a bus master. 
A bus slave cannot 


control 
the bus. 
Memory and 110 expansion 
boards are examples of bus slaves. 
The MULTI- 
BUS architecture 
provides for both 8 and 16-bit 
bus masters and slaves. 


Notice that a system may have a number of bus 
masters. 
Bus arbitration 
results when more than 
one master requests control ofthe bus at the same 
time. A bus clock is usually provided by one of the 
bus masters 
and may be derived independently 


from the processor clock. The bus clock provides a 
timing 
reference 
for resolving 
bus contention 
among multiple requests from bus masters. 
For 
example, a processor and a DMA (direct memory 
access) module may both request control of the 
bus. This feature allows different speed masters to 
share resources on the same bus. Actual transfers 
via the bus, however, proceed asynchronously 
with respect to the bus clock. Thus, the transfer 
speed 
is dependent 
on the transmitting 
and 
receiving devices only. 
The bus design prevents 


slow master modules from being handicapped 
in 
their attempts to gain control of the bus, but does 
not restrict the speed at which faster modules can 
transfer data via the same bus. Once a bus request 
is granted, single or multiple read/write 
transfers 


can proceed. The most obvious applications for the 
master-slave 
capabilities 
of the bus are multi- 
processor 
configurations 
and high-speed direct- 


memory-access (DMA) operations. 
However, the 


master-slave 
capabilities 
of the bus are by no 


means limited to these two applications. 


This section defines the signal lines that comprise 
the Intel MULTIBUS system ·bus. These signals 
are contained on either the PI or P2 connector of 
boards compatible with the MULTIBUS specifi- 
cation. 
The PI signal lines contain the address, 


data, 
bus control, bus exchange, 
interrupt 
and 
power supply lines. The P2 signal lines contain the 
optional auxiliary 
signal lines. 
Most signals on 
the bus are active-low. For example, a low level on 
a control signal on the bus indicates active, while a 
low level on an address or data signal on the bus 
represents logic "1" value. 


NOTE 


In this application 
note, a signal will be 


designated active-low by placing a slash (I) 
after the mnemonic for the signal. 


Appendix A contains a pin assignment 
list of the 


following signals: 


Initialization 
signal; resets the entire system to 
a known internal state. INIT I may be driven by 
one of the bus masters or by an external source 
such as a front panel reset switch. 


20 address lines; used to transmit the address of 
the memory location or I/O port to be accessed. 
The lines are labeled ADROI 
through ADR9/, 
ADRAI 
through ADRF I and ADRlOl 
through 
ADR13/. 
ADR131 
is the most significant 
bit. 
8-bit masters 
use 16 address 
lines (ADROI 
. 


ADRF I) for memory addressing and 8 address 
lines (ADROI 
- ADR7/) 
for I/O port selection. 
16-bit masters use all twenty address lines for 
memory 
addressing 
and 
12 address 
lines 
(ADROI 
- ADRB/) 
for I/O port selection. Thus, 
8-bit masters may address 64K bytes of memory 
and 256 I/O devices while 16-bit masters may 
address 
1 megabyte of memory and 4096 I/O 
devices. 
(The 8086 CPU actually 
permits 
16 
address bits to be used to specify I/O devices, 
the MULTIBUS specification, however, states 
that only the low order 12 address bits can be 
used to specify I/O ports.) 
In a 16-bit system, 
the ADROI line is used to.indicate whether a low 
(even) byte or a high (odd) byte of memory or 
I/O space is being accessed in a word oriented 
memory or I/O device. 


BHENI 


Byte 
High 
Enable; 
the address 
control 
line 
which is used to specify that data will be trans- 
ferred on the high byte (DAT81 
- DATF I) of the 
MULTIBUS 
data 
lines. 
With current 
.iSBC 
boards, this signal effectively specifies that a 
word (two byte) transfer is to be performed. This 
signal is used only in systems which incorporate 
sixteen bit memory or I/O modules. 


Inhibit 
RAM 
signal; 
prevents 
RAM memory 
devices from responding to the memory address 
on the system address bus. 
INH11 effectively 
allows ROM memory devices to override RAM 
devices when 
ROM and 
RAM memory 
are 


assigned the same memory addresses. 
INHlI 


may also be used to allow memory mapped I/O 
devices to override RAM memory. 


INH21 


Inhibit 
ROM 
signal; 
prevents 
ROM memory 


devices from responding to the memory address 
on the system address bus. 
INH21 effectively 


allows auxiliary 
ROM (e.g., a bootstrap 
pro- 
gram) to override ROM devices when ROM and 
auxiliary ROM memory are assigned the same 
memory addresses. 
INH21 may also be used to 


allow memory mapped I/O devices to override 
ROM memory. 


16 bidirectional 
data lines; used to transmit 
or 


receive information 
to or from a memory loca- 
tion or I/O port. DATFI being the most signifi- 
cant bit. 
In 8-bit systems, only lines DATOI 
- 
DAT7I are used (DAT7I being the most signi- 
ficant bit). In 16-bit systems, either 8 or 16lines 
may be used for data transmission. 


BCLKI 


Bus clock; the negative edge (high to low) of 
BCLKI 
is used to synchronize bus priority re- 


solution circuits. BCLKI 
is asynchronous to the 


CPU clock. It has a 100ns minimum period and 
a 35%to 65%duty cycle. BCLKI 
may be slowed, 


stopped, or single stepped for debugging. 


Constant 
clock; a bus signal which provides a 


clock signal of constant frequency for unspeci- 
fied general use by modules on the system bus. 
CCLKI 
has a minimum period of 100 ns and a 


35%to 65%duty cycle. 


Bus priority in signal; indicates to a particular 
master module that no higher priority module 
is requesting use of the system bus. BPRN I is 
synchronized with BCLK/. 
This signal is not 


bused on the backplane. 


Bus priority 
out signal; used with serial (daisy 


chain) bus priority resolution schemes. BPRO/ 
is passed to the BPRN/ 
input of the master 


module with the next lower bus priority. BPRO/ 
is synchronized with BCLK/. This signal is not 
bused on the backplane. 


Bus busy signal; an open collector line driven 
by the bus master currently in control to indicate 
that the bus is currently in use. BUSY/prevents 
all other master modules from gaining control 
of the bus. BUSYlis synchronized with BCLK/. 


Bus 
request 
signal; used with a parallel bus 
priority network to indicate that a particular 
master module requires use of the bus for one 
or more data transfers. 
BREQ/ is synchronized 


with BCLK/. 
This signal is not bused on the 
backplane. 


Common 
bus request; 
an open-collector line 


which is driven by all potential bus masters 
and is used to inform the current bus master 
that another master wishes to use the bus. 
If 


CBRQ/ is high, it indicates to the bus master 
that no other master is requesting the bus, and 
therefore, the present bus master can retain the 
bus. This saves the bus exchange overhead for 
the current master. 


A bus master 
provides 
separate 
read/write 


command signals for memory and 110 devices: 
MRDC/, MWTC/,IORC/ 
and IOWC/, 
as ex- 


plained below. When a read/write 
command is 


active, the address signals must be stabilized at all 
slaves on the bus. 
For this reason, the protocol 


requires that 
a bus master must issue address 


signals (and data signals for a write operation) at 
least 50 ns ahead ofissuing a read/write command 
to the bus, initiating 
the data transfer. 
The bus 


master must keep address signals unchanged until 
at least 50 ns after the read/write 
command is 


turned off, terminating 
the data transfer. 


A bus slave must provide an acknowledge signal to 


the bus master in response to a read or write 
command signal. 


Memory 
read 
command; 
indicates 
that 
the 
address of a memory location has been placed 
on the system address lines and specifies that 
the contents 
(8 or 16 bits) of the addressed 


location are to be read and placed on the system 
data bus. MRDC/ is asynchronous with respect 
to BCLK/. 


Memory 
write 
command; 
indicates 
that 
the 


address of a memory location has been placed 
on the system address lines and that data (8 or 
16 bits) has been placed on the system data bus. 
MWTC/ specifies that the data is to be written 
into the addressed memory location. MWTC/ is 
asynchronous with respect to BCLK/. 


I/O read command; 
indicates that the address 


of an input port has been placed on the system 
address bus and that the data (8 or 16 bits) at 
that input port is to be read and placed on the 
system data bus. 10RC/ is asynchronous with 
respect to BCLK/. 


I/O write command; indicates that the address 
of an output port has been placed on the system 
address bus and that the contents ofthe system 
data bus (8 or 16 bits) are to be output to the 
address 
port. 
10WC/ is asynchronous 
with 


respect to BCLK/. 


Transfer 
acknowledge 
signal; 
the required 


response of a slave board which indicates that 
the specified read/write 
operation 
has 
been 
completed. That is, data has been placed on, or 
accepted 
from, the system 
data 
bus lines. 


XACK/ is asynchronous with respect to BCLK/. 


used with a parallel interrupt 
resolution net- 
work. 
INTOI has the highest priority, while 
INT7I has 
lowest priority. 
Interrupt 
lines 
should be driven with open collector drivers. 


Interrupt 
acknowledge; 
an interrupt 
acknowl- 


edge line (INTA/), 
driven by the bus master, 
requests the transfer 
of interrupt 
information 


onto the bus from slave priority interrupt con- 
trollers (8259s or 8259As). The specific informa- 
tion 
timed 
onto the 
bus depends 
upon the 


implementation 
of the interrupt 
scheme. 
In 


general, the leading edge of INTAI 
indicates 


that the address bus is active while the trailing 
edge indicates that data is present on the data 
lines. 


MULTIBUS 
P2 Signal 
Lines 
- 
The signals 


contained on the MULTIBUS P2 auxiliary con- 
nector 
are used primarily 
by optional 
power 
back-up 
circuitry 
for memory 
protection. 
P2 
signals 
are not bused on the backplane, 
and 
therefore, require a separate connector for each 
board using the P2 signals. Present iSBC boards 
have a slot in the card edge and should be used 
with a keyed P2 edge connector. 
Use of the P2 


signal lines is optional. 


AC 
Low; this signal generated 
by the power 


supply goes high when the AC line voltage 
drops below a certain voltage (e.g., I03v AC in 
115v AC line voltage systems) indicating D.C. 
power will fail in 3 msec. ACLO goes low when 
all D.C. voltages return to approximately 
95% 
of the regulated value. This line must be pulled 
up by the optional standby power source, if one 
is used. 


Power fail interrupt; 
this signal interrupts the 
processor when a power failure occurs, it is 
driven by external power fail circuitry. 


Power 
fail 
sense; 
this line is the output of a 


latch which indicates that a power failure has 
occurred. It is reset by PFSR/. The power fail 


sense latch is part of external power fail cir- 
cuitry and must be powered by the standby 
power source. 


Power fail sense 
reset; this line is used to reset 


the power fail sense latch (PFSN I). 


Memory 
protect; 
prevents 
memory operation 
during period of uncertain 
DC power, by in- 


hibiting memory requests. 
MPROI 
is driven 
by external power fail circuitry. 


ALE 


Address 
latch 
enable; 
generated 
by the CPU 


(8085 or 8086) to provide an auxiliary address 
latch. 


Auxiliary 
Reset; 
this externally generated sig- 
nal initiates a power-up sequence. 


Bus 
master 
wait 
state; 
this signal 
indicates 


that the processor is in a wait state. 


Reserved 
- 
Several PI and P2 connector bus 


pins are unused. However, they should be regard- 
ed as reserved for dedicated use in future Intel 
products. 


Power 
Supplies 
- 
The power supply bus pins 


are detailed in Appendix A which contains 
the 


pin assignment 
of signals 
on the MULTIBUS 


backplane. 


It is the designer's 
responsibility 
to provide 


adequate bulk decoupling on the board to avoid 
current surges on the power supply lines. It is also 
recommended that 
you provide high frequency 


decoupling for the logic on your board. Values of 
22uF for +5v and +12v pins and lOuF for -5v and 
-12v pins are typical on iSBC boards. 


Beyond the definition of the MULTIBUS signals 
themselves, 
it is important 
to examine 
the 
operating 
characteristics 
of the bus. 
The AC 
requirements outline the timing of the bus signals 
and in particular, define the relationships between 
the various bus signals. On the other hand, the DC 
requirements 
specify the bus driver 
character- 


istics, maximum bus loading per board, and the 
pull-up/down 
resistors. 


The AC requirements 
are best presented 
by a 
discussion 
of the relevant 
timing 
diagrams. 
Appendix 
B contains 
a list of the MULTIBUS 
timing specifications. 
The following sections will 


discuss data transfers, 
inhibit operations, 
inter- 


rupt operations, MULTIBUS multi-master opera- 
tion and power fail considerations. 


Data Transfers 
- Data transfers on the MULTI- 


BUS system bus occur with a maximum band- 
width of 5 MHz for single or multiple read/write 
transfers. 
Due to bus arbitration 
and memory 
access time, a typical maximum transfer 
rate is 
often on the order of 2 MHz. 


Read Data 


Figure 
1 shows the read operation 
AC timing 
diagram. 
The address must be stable (tAS) for a 
minimum 
of 50 ns before command 
(IORC/ or 
MRDC/). 
This time is typically used by the bus 
interface to decode the address and thus provide 
the required 
device selects. 
The device selects 
establish 
the data 
paths 
on the user system in 


anticipation 
of the 
strobe 
signal 
(command) 
\'I'hich will follow. The minimum command pulse 
width is 100 ns. The address must remain stable 
for at least 50 ns following the command (tAH). 
Valid data should not be driven onto the bus prior 
to command, and must not be removed until the 
command is cleared. The XACK/ signal, which is 
a response 
indicating 
the specified read/write 
operation 
has been completed, must coincide or 


follow both the read access and valid data (tDXL). 
XACK/ must be held until the command is cleared 
(tXAH)· 
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Write Data 


The write operation AC timing diagram is shown 
in Figure 2. During a write data transfer, 
valid 


data 
must be presented 
simultaneously 
with a 


stable address. 
Thus, the write data setup time 


(tDS) has the same requirement 
as the address 


setup time (tAS). The requirement for stable data 
both 
before 
and 
after 
command 
(IOWC/ 
or 
MWTC/) enables 
the bus interface 
circuitry 
to 


latch data on either the leading or trailing edge of 
command. 


~o~: 
f";~~~'N-V I 


SONS MIN--f 
'AS 
}-- 
~ 
tAH }--SONS 
MIN 


~1~~~ESS 
~ 
STABLE 
ADDRESS c= j 
Ms:~i:R 


SONS 
MIN--!IDS 
~ 
-.fOHW~SONS 
MIN 


DATA 
-V 
STABLE 
v--- 


LINES 
----" 
WRITE 
DAT~ 
A 
_ 


I~ 
lUCK 
~ 
l~ 
'XAH ...• 
r--ON$ 
MIN 
r- 65NS 


-------- 
MAX 


XACKI 


A 16-bit master may transfer data on the MULTI· 
BUS data 
lines 
using 
8-bit 
or 16-bit paths 


depending 
on whether 
a byte or word (2 byte) 


operation 
has been specified. 
(A word transfer 
specified with an odd I/O or memory address will 
actually be executed as two single byte transfers.) 
An 8-bit master may only perform byte transfers 
on the MULTIBUS data lines DATO/ - DAT7I. 


In 
order to maintain 
compatibility 
with older 


8-bit masters and slaves, a byte swapping buffer 
is included in all new 16-bit masters 
and 16-bit 
slaves. In the iSBC product line, all byte transfers 
will take place on the low 8 data lines DATO/ - 
DAT7I. 
Figure 3 contains a example of 8/16-bit 


data 
driver 
logic for 16-bit master 
and 
slave 
systems. 
In the 8/16-bit system, there are three 
sets 
of buffers; 
the lower byte buffer 
which 
accesses DATOI - DAT7I, the upper byte buffer 
which accesses DAT81 - DATF/, 
and the swap 
byte buffer which accesses the MULTIBUS data 
lines DATOI 
- DAT7I and transfers 
the data 
tolfrom the on-board data bus lines D8 - DF. 


Figure 4 summarizes the 8 and 16-bit data paths 
used for three types ofMULTIBUS transfers. Two 
signals control the data transfers. 


Byte High Enable (BHEN I) active indicates that 
the bus is operating 
in sixteen bit mode, and 
Address Bit 0 (ADRO/) defines an even or odd byte 
transfer address. 


On the first type of transfer, BHEN I is inactive, 
and ADROI is inactive indicating the transfer of 
an even eight bit byte. The transfer takes place 
across data lines DATOI - DAT7I. 


On the second type oftransfer, BHEN I is inactive, 
and ADROI is active indicating the transfer of a 
high (odd) byte. On this type of transfer, the odd 
(high) byte is transferred through the Swap Byte 
Buffer to DATOI - DAT7I. This makes eight bit 
and sixteen bit systems compatible. 
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The 
third 
type 
of transfer 
is a 16 bit (word) 
transfer. 
This 
is indicated 
by BHEN/being 


active, and ADRO/ being inactive. On this type of 
transfer, 
the 
low (even) byte 
is transferred 
on 
DATOI 
- DAT7I 
and 
the 
high 
(odd) byte 
is 
transferred 
on DAT81 - DATF/. 


Note that 
the condition 
when both BHENI 
and 
ADROI are active is not used with present iSBC 
boards. 
This condition could be used to transfer a 


high odd byte of data on DAT81 - DATF/, 
thus 


eliminating 
the need for the swap byte buffer. 


However, this is not a recommended transfer type, 
because it eliminates 
the capability 
of communi- 
cating with 8-bit modules. 


Inhibit 
Operations 
- 
Bus inhibit operations are 


required by certain bootstrap and memory mapped 
110 configurations. 
The purpose of the inhibit 


operation is to allow a combination of RAM,ROM, 
or memory 
mapped 
110 to occupy 
the same 
memory address space. In the case of a bootstrap, 
it may be desirable to have both ROM and RAM 
memory occupy the same address space, selecting 
ROM instead of RAM for low order memory only 
when the system is reset. A system designed to use 


memory mapped 110, which has actual memory 
occupying 
the memory 
mapped 
110 address 


space, may need to inhibit RAM or ROM memory 
to perform its functions. 
There are two essential requirements 
for a success- 


ful inhibit operation. 
,The first is that the inhibit 


signal must be asserted: as soon as possible, within 
a maximum 
of 100 ns (tCI), after stable address. 


The second requirement 
for a successful inhibit 


operation is that the acknowledge must be delayed 
(tXACKB) 
to allow 
the inhibited 
slave 
to ter- 


minate 
any 
irreversible 
timing 
operations 
in- 


itiated by detection of a valid command prior to its 
inhibit. 
This situation 
may arise because a command can 


be asserted within 50 ns after stable address (tAS) 
and yet inhibit 
is not required until 100 ns (tm) 


after stable address. 
The acknowledge delay time 


(tXACKB) is a function 
of the cycle time of the 


inhibited slave memory. 
Inhibiting 
the iSBC 016 


RAM board, for example, requires a minimum of 
1.5 usee. 
Less time is typically needed to inhibit 


other memory modules. For example, the iSBC 104 
board requires 475 ns. 
Figure 5 depicts a situation 
in which both RAM 
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and 
PROM 
memory 
have 
the 
same 
memory 


addresses. 
In this case, PROM inhibits 
RAM, 
producing 
the effect of PROM overriding 
RAM. 
After address is stable, local selects are generated 
for both the PROM and the RAM. The PROM local 
select 
produces 
the 
INHl/ 
signal 
which 
then 
removes the RAM local select and its driver enable. 
Because the slave RAM has been inhibited after it 
had already 
begun its cycle, the PROM XACK/ 


must be delayed (tXACKB) until after the latest 
possible 
acknowledgement 
from 
the 
RAM 


(tXACKA)· 


Interrupt 
Operations 
- The MULTIBUS inter- 
rupt lines INTO/ - INT7/ are used by a MULTI- 
BUS master to receive interrupts, from bus slaves, 
other bus masters or external logic such as power 
fail logic. A bus master may also contain internal 
interrupt 
sources which do not require the bus 
interrupt 
lines to interrupt the master. 
There are 


two interrupt 
implementation 
schemes used by 
bus interrupts, 
Non Bus Vectored Interrupts 
and 


Bus Vectored 
Interrupts. 
Non Bus Vectored 


Interrupts 
do not convey interrupt vector address 


information 
on the bus. Bus Vectored Interrupts 


are interrupts 
from slave Priority Interrupt 
Con- 


trollers (PICs) which do convey interrupt 
vector 


Non Bus Vectored Interrupts 


Non Bus Vectored Interrupts 
are those interrupts 
whose interrupt vector address is generated by the 
bus master 
and do not require the MULTIBUS 
address 
lines for transfer 
of the interrupt 
vector 
address. The interrupt vector address is generated 
by the interrupt 
controller 
on the master 
and 
transferred 
to the processor over the local bus. The 


source of the interrupt can be on the master module 
or on other bus modules, in which case the bus 
modules 
use the MULTI BUS interrupt 
request 
lines (INTO/ - INT7/) to generate 
their interrupt 


requests 
to the bus master. 
When an interrupt 
request line is activated, the bus master performs it 
own interrupt 
operation 
and processes the inter- 
rupt. 
Figure 6 shows an example 
of Non Bus 


Vectored Interrupt 
implementation. 


Bus Vectored Interrupts 


Bus Vectored Interrupts 
(Figure 7) are tp.ose inter- 
rupts which transfer 
the interrupt 
vector address 
along 
the MULTIBUS 
address 
lines from the 


slave to the bus master using the INTA/ command 
signal for synchronization. 
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When an interrupt request from the MULTIBUS 
interrupt lines INTOI - INT7I occurs, the interrupt 
control logic on the bus master 
interrupts 
its 


processor. 
The 
processor 
on the bus master 


generates an INTAI command which freezes the 
state of the interrupt 
logic on the MULTIBUS 


slaves for priority resolution. The bus master also 
locks (retains 
the bus between bus cycles) the 
MULTIBUS 
control 
lines 
to guarantee 
itself 


consecutive bus cycles. 
After the first INTAI 
command, the bus master's interrupt control logic 
puts 
an interrupt 
code on to the MULTIBUS 


address lines ADRBI -ADRAI. 
The interrupt code 
is the address of the highest priority active inter- 
rupt request line. At this point in the Bus Vectored 


Interrupt procedure, two different sequences could 
take place. 
The difference occurs, because the 


MULTIBUS specification 
can support 
masters 


which 
generate 
one additional 
INTAI 
(8086 


masters) or two additional 
INTA/s 
(8080A and 


8085 masters). 


If the bus master generates one additional INTAI, 
this second INTAI 
causes the bus slave interrupt 


control logic to transmit 
an interrupt vector 8-bit 


pointer on the MULTIBUS data lines. The vector 
pointer is used by the bus master to determine the 
memory address of the interrupt service routine. 


If the 
bus master 
generates 
two additional 
INTAls, 
these two INTAI 
commands allow the 


bus slave to put a two byte interrupt vector address 
on to the MULTIBUS data lines (one byte for each 
INTA/). 
The interrupt 
vector address is used by 


the bus master to service the interrupt. 


The MULTIBUS 
specification 
provides for only 


one type of Bus Vectored Interrupt 
operation in a 


given system. 
Slave boards which have an 8259 


interrupt 
controller 
are only capable of 3 INTAI 


operation 
(2 additional 
INTA/s 
after 
the first 
INTA/). 
Slave boards with the 8259A interrupt 


controller 
are capable 
of either 
2 INTAI 
or 3 


INTAI 
operation. 
All slave boards 
in a given 


system must operate in the same way (2INTA/s or 
3 INTA/s) 
if Bus Vectored Interrupts 
are to be 
used. 
However, 
the MULTIBUS 
specification 
does provide for Bus Vectored Interrupts 
and Non 
Bus Vectored Interrupts 
in the same system. 


MULTIBUS@ 
Multi-Master 
Operation 
- 
The 
MULTIBUS system bus can accommodate several 
bus masters on the same system, each one taking 
control of the bus as it needs to affect data trans- 
fers. The bus masters request bus control through 
a bus exchange 
sequence. 


Two bus exchange 
priority resolution techniques 


are discussed, 
a serial technique 
and a parallel 
technique. 
Figures 
8 and 9 illustrate 
these two 
techniques. 
The 
bus exchange 
operation 
dis- 
cussed later is the same for both techniques. 


Serial Priority Technique 


Serial priority resolution 
is accomplished 
with a 


daisy chain technique (see Figure 8). The priority 
input 
(BPRN/) 
of the highest 
priority 
master 
is 
tied to ground. 
The priority output (BPRO/) 
of the 


highest 
priority 
master 
is then connected 
to the 


priority input (BPRN/) 
of the next lower priority 


master, and so on. Any master generating 
a bus 


request will set its BPROI 
signal high to the next 


lower priority master. 
Any master seeing a high 
signal on its BPRNI 
line will sets its BPROI 
line 
high, thus passing 
down priority information 
to 


lower priority 
masters.· 
In this implementation, 


the bus request line (BREQ/) is not used outside of 
the 
individual 
masters. 
A limited 
number 
of 


masters 
can be accommodated 
by this technique, 


due to gate delays through the daisy chain. 
Using 
the current 
Intel MULTIBUS 
controller 
chip on 
the master boards up to 3 masters 
may be accom- 


modated if a BCLKI 
period of 100 ns is used. 
If 
more bus masters are required, either BCLKI 
must 


be slowed or a parallel priority technique 
used. 


Parallel 
Priority Technique 


In the parallel 
priority technique, 
the priority 
is 


resolved in a priority resolution 
circuit in which 
the highest priority BREQI input is encoded with 
a priority encoder chip (74148). This coded value is 
then decoded with a priority decoder chip (74S138) 
to activate 
the 
appropriate 
BPRNI 
line. 
The 
BPROI 
lines are not used in the parallel 
priority 


scheme. 
However, since the MULTIBUS 
back- 


plane contains 
a trace from the BPRNI 
signal of 


one card slot to the BPROI 
signal of the adjacent 


lower card slot, the BPROI 
must be disconnected 


from the bus on the board or the backplane 
trace 


must be cut. 
A practical 
limit of sixteen masters 
can be accommodated 
using the parallel 
priority 


technique 
due to physical bus length limitations. 


Figure 
9 contains 
the schematic 
for a typical 
parallel resolution network. 
Note that the parallel 
priority 
resolution 
network 
must 
be externally 


supplied. 
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MULTIBUS® Exchange 
Operation 
- 
A timing 
diagram for the MULTIBUS exchange operation 
is shown 
in Figure 
10. 
This 
implementation 


example uses a parallel resolution scheme, how- 
ever, the timing would be basically 
the same for 


the serial resolution scheme. 


In this example, master A has been assigned 
a 


lower priority than master B. The bus exchange 
occurs because master B generates a bus request 
during a time when master A has control of the 
bus. 


The 
exchange 
process 
begins 
when 
master 
B 
requires the bus to access some resource such as an 
I/O or memory module while master A controls the 
bus. 
This internal 
request is synchronized 
with 


the 
trailing 
edge (high 
to low) of BCLKI 
to 


generate a bus request (BREQ/). The bus priority 
resolution circuit changes the BPRNI 
signal from 


active (low) to inactive (high) for master A and 
from inactive to active for master 
B. 
Master A 


must first complete the current bus command if 
one is in operation. 
After master A completes the 


command, 
it sets BUSYI inactive 
on the next 


trailing edge ofBCLK/. 
This allows the actual bus 


exchange 
to occur, because master A has relin- 
quished control of the bus, and master B has been 
granted 
its BPRN/. 
During this time, the drivers 


for master 
A are disabled. 
Master B must take 
control of the bus with the next trailing 
edge of 


BCLKI 
to complete the bus exchange. 
Master B 


takes control by activating 
BUSYI and enabling 


its drivers. 


It is possible for master A to retain control of the 
bus and prevent master 
B from getting 
control. 


Master A activates the Bus Override (or Bus Lock) 
signal which keeps BUSYI active allowing con- 
trol of the bus to stay 
with master 
A. 
This 


guarantees 
a master 
consecutive 
bus cycles for 


software 
or hardware 
functions 
which 
require 


exclusive, continuous 
access to the bus. 


Note that in systems with only a single master it is 
necessary to ground the BPRNI 
pin of the master, 


if slave boards are to be accessed. In single board 
systems which use a CPU board capable of Bus 
Vectored Interrupt operation, the BPRNI 
pin must 


also be grounded. 


In a single master system bus transfer efficiency 
may be gained if the BUS OVERRIDE signal is 
kept active continuously. 
This permits the master 


to maintain 
control of the bus at all times, there- 


fore saving the overhead of the master reacquiring 
the bus each time it is needed. 


The CBRQI 
line may be used by a master 
in 
control of the bus to determine if another master 
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requires the bus. If a master currently in control ot 
the bus sees the CBRQ/ 
line inactive, 
it will 
maintain 
control of the bus between adjacent bus 


accesses. Therefore, when a bus access is required, 
the master saves the overhead of reacquiring the 
bus. If a current bus master sees the CBRQ/ line 
active, it will then relinquish control of the bus 
after the current bus access and will contend for 
the bus with the other master(s) requiring the bus. 
The relative priorities of the masters will deter- 
mine which master receives the bus. 


Note that except for the BUS OVERRIDE state, no 
single master may keep exclusive control of the 
bus. 
This is true because it is impossible for the 


CPU on a master to require continuous access to 
the bus. Other lower priority masters will always 
be able to gain access to the bus between accesses 
of a higher priority master. 


Power 
Fail Considerations 
- The MULTIBUS 


P2 connector signals provide a means of handling 
power failures. 
The circuits required for power 
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failure detection and handling 
are optional and 
must be supplIed by the user. 
Figure 11 shows 


the timing of a power fail sequence. 


The power supply monitors 
the AC power level. 


When power drops below an acceptable value, the 
power supply raises ACLO which tells the power 
fail logic that a minim um ofthree milliseconds will 
elapse before DC power will (all below regulated 
voltage levels. 
The power fail logic sets a sense 
latch (PFSN/) and generates an interrupt (PFIN I) 
to the processor 
so the processor 
can store its 


environment. 
After a 2.5 millisecond timeout, the 
memory protect signal (MPRO/) is asserted by the 
power fail logic preventing 
any memory activity. 


As power falls, 
the memory goes on standby 
power. 
Note that 
the power fail logic must be 
powered from the standby source. 


As the AC line revives, the logic voltage level is 
monitored by the power supply. 
After power has 
been at its operating 
level for one millisecond 
minimum, the power supply sets the signal ACLO 
low, beginning 
the restart 
sequence. 
First, the 
memory protect line (MPRO/) 
then the initialize 
line (INIT I) become inactive. The bus master now 
starts running. 
The bus master checks the power 
fail latch (PFSN /) and, ifit finds it set, branches to 


a power up routine which resets the latch (PFSR/), 
restores the e.nvironment, and resumes execution. 


Note that INITI is activated only after DC power 
has risen to the regulated voltage levels and must 
stay low for five milliseconds minimum before the 
system is allowed to restart. 
Alternatively,INITI 


may be held low through an open collector device 
by MPROI. 


How the power failure equipment is configured is 
left to the system designer. 
The backup power 


source may be batteries 
located on the memory 


boards 
or more elaborate 
facilities 
located off- 
board. 
The 
location 
of the 
power 
fail 
logic 


determines which MULTIBUS power fail lines are 
used. Pins on the P2 connector have been specified 
for the power failure functions for use as needed. 


To further clarify the location and use of the power 
fail circuitry, an example of a typical power fail 
system block diagram is shown in Figure 12. A 
single board computer and a slave memory board 
are contained in the system. It is desired to power 
the memory circuit elements of the memory board 
from auxiliary power. The single board computer 
will remain 
on the main power supply. 
To ac- 


complish this, user supplied power fail logic and 


an auxiliary power supply have been included in 
the system. 


The single board computer is powered from the PI 
power lines 
and 
accesses 
the P2 signal 
lines 


PFIN/, 
PFSNI 
and PFSRI 
(only the P2 signal 
lines used by a particular 
functional 
block are 


shown on the block diagram). 
The PFSRI 
line is 
driven from two sources: a front panel switch and 
the single board computer. The front panel switch 
is used during normal power-up to reset the power 
fail sense latch. 
The single board computer uses 


the PFSRI 
line to reset the latch during a power-up 


sequence after a power failure. 
Current single 
board 
computers 
must 
access the PFSNI 
and 


PFSRI 
signals 
either 
directly 
with 
dedicated 


circuitry and a P2 pin connection or through the 
parallel I/O lines with a cable connection from the 
parallel I/O connector to the P2 connector. 


The slave memory board uses both the PI and P2 
power lines, the P2 power lines are used (at all 
times) to power the memory circuit elements and 
other support circuits, the PI power lines power all 
other circuitry. 
In addition, the MPROI 
line is 


input and used to sense whEmmemory contents 
should be protected. 


The power fail logic contains the power fail sense 
latch, and uses the PFSRI 
and ACLO lines for 


inputs and the PFINI 
PFSN/, 
and MPROI 
lines 


for outputs. 
The power fail logic must be powered 


by the P2 power lines. 


DC Requirements 
- The drive and load charac- 
teristics of the bus signals are listed in Appendix 
C. The physical locations of the drivers and loads, 
as well as the terminating 
resistor value for each 


bus line, are also specified. Appendix D contains 
the MULTIBUSpower specifications. 


MULTIBUS@ Slave Interface 
Circuit Elements 


There are three basic elements 
of a slave bus 


interface: 
address 
decoders, bus drivers, 
and 


control signal logic. This section discusses each of 
these elements in general terms. A description of a 
detailed implementation 
of a slave interface 
is 


presented in a later section of this application note. 


Address 
Decoding 
- 
This 
logic decodes the 


appropriate 
MULTIBUS address bits into RAM 


requests, ROM requests, or I/O selects. Care must 
be taken in the design of the address decode logic 
to ensure flexibility in the selection of base address 
assignments. 
Without this flexibility, restrictions 


may be placed upon various system configura- 
tions. 
Ideally, switches and jumper connections 


should 
be associated 
with the decode logic to 


permit field modification of base address assign- 
ments. 


The initial step in designing the address decode 
portion of a MULTIBUS interface is to determine 
the required number of unique address locations. 
This 
decision 
is influenced 
by the fact 
that 


address decoding is usually done in two stages. 
The first 
stage 
decodes the base address, 
pro- 


ducing 
an enable 
for the second stage 
which 


generates 
the actual device selects for the user 


logic. 
A convenient implementation 
of this two 


stage decoding scheme utilizes a pair of decoders 
driven by the high order bits ofthe address for the 
first stage and a second decoder for the low order 
bits of the address bus. This technique forces the 
number of unique address locations to be a power 
of two, based at the address decoded by the first 
stage. 
Consider the scheme illustrated 
in Figure 


13. 


As shown in Figure 13,the address bits A4 -ABare 
used to produce switch selected outputs of the first 
stage of decoding. The 1 out of 8 binary decoders 


have been used. The top decoder decodes address 
lines A4 - A7, and the bottom decoder decodes 
address lines A8· AB. If only address lines AO-A7 
are being used for device selection, as in the case of 
I/O 
port selection in 8-bit systems, 
the bottom 


decoder may be disabled by setting switch S2 to the 
ground position. 
Address lines A7 and AB drive 
enable 
inputs 
E2 or E3 of the decoders. 
The 
address 
lines AO - A3 enter the second stage 
address decoder to produce 8 user device selects. 
The second stage decoder must first be enabled by 
an address that corresponds to the switch-selected 
base address. 


Address decoding must be completed before the 
arrival of a command. 
Since the command may 
become active within 50 ns after stable address, 
the decode logic should be kept simple with a 
minimal number of layers of logic. Furthermore, 
the timing is extremely critical in systems which 
make use of the inhibit lines. 


A linear or unary select scheme in which no binary 
encoding of device address (e.g., address bit AO 
selects device 0, address bit Al selects device 1, 
etc.) is performed is not recommended because the 
scheme 
offers 
no protection 
in case multiple 
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devices are simultaneously 
selected, and because 


the addressing within such a system is restricted 
by the extent ofthe address space occupied by such 
a scheme. 


Data 
Bus Drivers 
- 
For user designed logic 


which simply receives data from the MULTIBUS 
data lines, this portion of the bu!] interface logic 
may only consist of buffers. Buffers are required 
to ensure that maximum allowable bus loading is 
not exceeded by the user logic. 


In systems 
where the user designed logic must 


place data onto the MULTIBUS data lines, three- 
state drivers are required. These drivers should be 
enabled 
only when a memory read command 


(MRDC/) or an I/O read command 
(IORC/) is 


present and the module has been addressed. 


When both the read and write functions are re- 
quired, parallel bidirectional bus drivers (e.g., Intel 
8226,8287, etc.) are used. A note of caution must be 
included for the designer who uses this type of 
device. 
A problem may arise if data hold time 


requirements 
must 
be satisfied 
for user logic 


following write operations. 
When bus commands 


are used to directly produce both the chip select for 
the bidirectional bus driver and a strobe to a latch 
in the user logic, removal of that signal may not 
provide the user's latch with adequate data hold 
time. Depending on the specifics of the user logic, 
this 
problem 
may be solved 
by permanently 


enabling 
the data buffer's receiver circuits and 
controlling only the direction of the buffers. 


Control 
Signal Logic - The control signal logic 


consists of the circuits that forward the I/O and 
memory read/write 
commands to their respective 


destinations, 
provide 
the bus with 
a transfer 


acknowledge 
response, 
and 
drive 
the system 


interrupt lines. 


Bus Command Lines 


The MULTIBUS information 
transfer 
protocol 


lines 
(MRDC/, 
MWTC/, 
IORD/. 
and 
IOWC/) 


should be buffered by devices with very high speed 
switching. 
Because the bus DC requirements 


specify that each board may load these lines with 
2.0 mA, Schottky devices are recommended. 
LS 


devices are not recommended due to their poor 
noise immunity. 
The commands should be gated 


with a signal indicating the base address has been 
decoded to generate read and write strobes for the 
user logic. 


Transfer Acknowledge Generation 


The user interface transfer acknowledge genera- 
tion logic provides 
a transfer 
acknowledge re- 


sponse, XACK/, to notify the bus master that write 
data provided by the bus master has been accepted 
or that read data it has requested is available oil. 
the MULTIBUS data lines. XACK/ allows the bus 
master to conclude its current instruction. 


Since XACK/ timing requirements depend on both 
the CPU of the bus master and characteristics 
of 
the user logic, a circuit is needed which will provide 
a range of easily modified acknowledge responses. 


The transfer acknowledge signals must be driven 
by three-state drivers which are enabled when the 
bus interface 
is addressed 
and a command 
is 
present. 


Interrupt 
Signal Lines 


The asynchronous 
interrupt lines must be driven 


by open collector devices with a minimum drive of 
16 mA. 


In a typical Non Bus Vectored Interrupt 
system, 
logic must be provided to assert and latch-up an 
interrupt 
signal. 
In addition 
to driving 
the 
MULTI BUS interrupt lines, the latched interrupt 
signal would be read by an I/O operation such as 
reading the module's status. 
The interrupt signal 


would be cleared by writing to the status register. 


III. MULTmUS<!>SLAVE DESIGN 
EXAMPLE 


A MULTIBUS slave design example has been 
included in this application note to reinforce the 
theory previously discussed. The design example 
is of general purpose I/O slave interface. 
This 
design example could easily be modified to be used 
as a slave memory interface 
by buffering the 


address 
signals 
and 
using 
the 
appropriate 
MULTI BUS memory commands. 
In addition, to 
help the reader better understand 
an application 
for an I/O slave interface, two Intel 8255AParallel 
Peripheral Interface (PPI) devices are shown con- 
nected to the slave interface. 


The design example is shown in both 8/16-bit 
version and an 8-bit version. The 8/16-bit version 


is an I/O 
interface 
which will permit a 16-bit 


master to perform 8 or 16 bit data transfers. 
8-bit 


masters may also use the 8/16-bit version of the 
design example to perform 8-bit data transfers. 


The 8-bit version of the design example may be 
used by both 8 or 16-bit masters, 
but will only 


perform 8-bit data transfers. 
It does not contain 
the 
circuitry 
required 
to perform 
16-bit data 


transfers. 


Both the 8/16-bit version and the 8-bit version of 
the design example were implemented on an iSBC 
905 prototype board. 
The schematics for each of 


the examples are given in Appendices F and G. 


This 
section describes the organization 
of the 


slave 
interface 
from two points 
of view, the 


functional 
point of view and the programming 


characteristics. 
First, 
the principal 
functions 


performed by the hardware are identified and the 
general data flow is illustrated. 
This point of view 


is intended 
as an introduction 
to the detailed 
description provided in the next section; Theory of 
Operation. 
In the second point 
of view, the 


information needed by a programmer to access the 
slave is summarized. 


Functional 
Description 
- 
The function of this 


I/O slave is to provide the bus interface logic for 
general purpose I/O functions and for two Intel 
8255A Parallel Peripheral Interface (PPI) devices. 
Eight device selects (port addresses) are available 
for general purpose I/O functions. 
One of these 


device select lines is used to read and reset the state 
of an interrupt 
status 
flip-flop, the other seven 
device selects are unused 
in this design. 
An 
additional 
eight I/O 
device port addresses 
are 


used by the two 8255A devices; four I/O 
port 
addresses per 8255A (three I/O port address for 
the three parallel ports A, B, and C and the fourth 
I/O port address for the device control register). 


Figure 14 contains a functional block diagram of 
the slave design example. 
This block diagram 


shows the fundamental 
circuit elements of a bus 


slave: 
bidirectional 
data bus drivers/receivers, 


address decoding logic and bus control logic. Also 
shown is the address decoding logic for the low 
order four bits, the interrupt logic which is selected 
by this decoding logic, and the two 8255A devices. 
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Figure 14. MULTIBUS'" Slave Design Example 
Functional 
Block Diagram 


Programming 
Characteristics 
- 
The slave 
design example provides 16 110 port addresses 
which may be accessed by user software. 
The 


base address of the 16 contiguous port addresses 
is selected by wire wrap connections on the proto- 
type board. 
The wire wrap connections specify 


address 
bits ADR4/ - ADRB/. 
They allow the 


selection 
of a base 
address 
on any 
16 byte 


boundary. 
Twelve address bits (ADRO/ -ADRB/) 


are used since 16-bit (8086 based) masters use 12 
bits to specity 110 port addresses. If an 8 bit (8080 
or 8085based) master is used with this slave board, 
the high order address bits (ADRB/ -ADRB/) must 
not be used by the decoding circuits; a wire wrap 
jumper position (ground position) is provided for 
this. 


The 16 110 port addresses are divided into two 
groups of8 port addresses by decoding address line 
ADR3/. 
Port addresses XXO- XX7 are used for 


general 
110 functions 
(XX indicates 
any hexi- 
decimal digit combination). 
Port address XXOis 
used for accessing the interrupt status flip-flop and 


port addresses 
XXI - XX7 are not used in this 


example. 
Port addresses XX8 - XXF are used for 


accessing the PPIs. 
If port addresses XX8 - XXF 


are selected, then ADRO/ is used to specify which 
of two PPIs are selected. 
If the address is even 


(XX8,XXA,XXC,or XXE)then one PPI is selected. 
If the address is odd (XX9, XXB, XXD, or XXF), 
then the other PPI is selected. ADR1/ and ADR2/ 
are 
connected 
directly 
to the PPIs. 
Table 
1 


summarizes 
the 110 port addresses of the slave 


design example. 
Note that if a 16-bit master is 


used, it is possible to access the slave in a byte or 
word mode. 
If word access IS used with port 


address 
XX8, XXA, XXC, or XXE, then 
16 bit 


transfers 
will occur between the PPIs 
and the 


master. 
These 16 bit transfers 
occur because an 


even address has been specified and the MULTI- 
BUS 
BHEN / signal 
indicates 
that 
a 16-bit 


transfer is requested. 


In the preceding section, each of the slave design 
example 
functional 
blocks was identified 
and 


briefly explained. This section explains how these 
functions are implemented. 
For detailed circuit 


information, refer to the schematics in Appendices 
F and G. The schematic in Appendix F is on a 
foldout page so that the following text may easily 
be related to.the schematic. 


The discussion ofthe theory ofoperation is divided 
into five segments, 
each of which discusses 
a 


different function performed by the MULTIBUS 
slave design example. 
The five segments are: 


1. Bus address decoding 


2. Data buffers 


3. Control signals 


4. Interrupt logic 


5. PPI operation 


Each of these topics are discussed with regard to 
the 
8/16·bit 
version 
of the design 
example; 


followed by a discussion of the circuit elements 
which are required by the 8-bit version of the 
interface. 


Bus Address 
Decoding 
- Bus address decoding 


is performed by two 82051 out of8 binary decoders. 
One decoder (A3) decodes address bits ADRB/ - 
ADRB/ 
and 
the second decoder (A2) decodes 


address bits ADR4/ - ADR7/. 
The base address 


Table 1 


SLAVE 
DESIGN 
EXAMPLE 
PORT ADDRESSES 


I/O PORT ADDRESS 
READ 
WRITE 


BYTE ACCESS 


XXO 
Bit 0 = Interrupt 
Status 
Reset Interrupt 
Status 


XX1 - XX? 
Unused 
Unused 


XX8 
P.arallel Port A, Even PPI 
Parallel 
Port A, Even PPI 


XX9 


; 


Parallel 
Port A, Odd 
PPI 
Parallel 
Port A, Odd 
PPI 


XXA 
" 
Parallel 
Port B, Even PPI 
Parallel 
Port B, Even PPI 


XXB 
Parallel 
Port B, Odd PPI 
Parallel 
Port B, Odd PPI 


XXC 
Parallel 
Port C, Even PPI 
Parallel 
Port C, Even PPI 


XXD 
Parallel 
Port C, Odd 
PPI 
Parallel 
Port C, Odd PPI 


XXE 
Illegal 
Condition 
Control, 
Even PPI 


XXF 
Illegal 
Condition 
Control, 
Odd 
PPI 


WORD 
ACCESS 


XXO 
Bit 0 = Interrupt 
Status 
Reset Interrupt 
Status 


XX2 - XX6 
Unused 
Unused 


XX8 
Parallel 
Port A, Even and Odd 
PPls 
lParaliel 
Port A, Even and Odd PPls 


XXA 
Parallel 
Port B, Even and Odd 
PPls 
Parallel 
Port B, Even and Odd 
PPls 


XXC 
Parallel 
Port C, Even and Odd PPls 
Parallel 
Port C, Even and Odd 
PPls 


XXE 
Illegal 
Condition 
Control, 
Even and Odd 
PPls 


XX = Any 
hex digits, 
assigned 
by jumpers; 
XX defines 
the base address. 


selected is determined by the position of wire wrap 
jumpers. 
The outputs of the two decoders are 


ANDed together to form the BASE ADR SELECT/ 
signal. 
This signal 
specifies the base address 


for a group of 16 I/O ports. Using the wire wrap 
jumper positions shown in the schematic, a base 
address of E3 has been selected. Therefore, this 
MULTIBUS slave board will respond to I/O port 
addresses in the E30 - E3F range. 


If this slave board is to be used with 8-bit MULTI- 
BUS masters, the high order address bits must not 
be decoded. 
Therefore, 
the wire wrap jumper 


which selects the output of decoder A3 must be 
placed in the top (ground) position (pin 10 of gate 
A9 to ground). 


The low order 4 address lines (ADRO/- ADR3/) are 
buffered 
and 
inverted 
using 74LS04 inverters. 


These 
address 
lines are input 
to an 8205 for 


decoding a chip select for the interrupt logic; the 
address lines are also used directly by the PPls. 
LS-Series logic is required for buffering to meet the 
MULTIBUS specification for IlL (low level input 


current). S-Series or standard series logic will not 
meet this specification. 


Address decoder A4 is used to decode addresses 
E30 - E37. The CSO/ output ofthis decoder is used 
to select the interrupt logic, thus I/O port address 
E30 is used to read and reset the interrupt latch. 
The remaining 
outputs from decoder A4 (CSl/ 
- 


CS7/) are not used in this example. 
They would 


normally be used to select other functions in a 
slave board with more capability. 
Note that in the 


schematic 
shown in Appendix 
G for the 8-bit 


version of this slave design example, the high 
order (ADR8/ - ADRB/) 
address 
decoder is not 


included and the BHEN/ signal is not used. 


Data 
Buffers 
- 
Intel 
8287 8-bit parallel 
bi- 


directional 
bus drivers are used for the MULTI- 


BUS data lines DATOI 
- DATF/. 
In the 8/16-bit 


version of the slave board, three 
8287 drivers 


are used. 


When an 8-bit data transfer 
is requested, either 


driver A5, which is connected to on-board data 


lines DO- D7, or driver A6, which is connected to 
on-board data lines D8 - DF, is used. 
If a byte 
transfer is requested from an even address, driver 
A5 will be selected. If a byte transfer from an odd 
address is requested, driver A6 will be selected. All 
byte transfers 
take place on MULTIBUS data 
lines 
DATOI 
- DAT7I. 
When a word (16-bit) 
transfer is requested from an even address, drivers 
A5 and A7will be used. Note that if a user program 
requests 
a word transfer 
from an odd address, 
16-bit masters 
in the iSBC product 
line will 


actually perform two byte transfer requests. 


The logic which determines 
the chip selection 


(8287 input signal OE, output enable) signals for 
the bus drivers uses the low order address bit 
(ADRO/) 
and 
the 
buffered 
Byte High 
Enable 


signal (BHENBLI). 
Note that the MULTIBUS 


signal BHENI 
has been buffered with an 74LS04 
inverter. 
This is done to meet the bus address line 
loading specification. 
The SWAP BYTEI 
signal 


which is generated is qualified by the BD ENBLI 
signal and used to select the bus drivers. 


The steering pin for the 8287 drivers is labelled T 
(transmit) and is driven by the signal RD. When 
an input (read) request is active or when neither a 
read or write command 
is being serviced, the 
direction of data transfer of the 8287 will be set for 
B to A. 


The 8287 drivers are set to point IN (direction B to 
A) when no MULTIBUS 110 transfer command is 
being serviced for two reasons. 
First, if the driver 


were pointed OUT (direction A to B) and a write 
command occured, it would be necessary to turn 
the buffers IN and set the OE (output enable) 
signal active before the data could be transferred 
to the on-board bus. 
A possibility of a "buffer- 


fight" could occur in some designs if the OE signal 
permitted an 8287 to drive the MULTIBUS data 
lines momentarily before the steering signal could 
switch the direction of the 8287. In this case, both 
the MULTIBUS master and the slll-vewould be 
driving the data lines; this is not recommended. 
(In this particular design, the steering signal will 
always 
stabilize 
before the OE signal becomes 


active.) 


The second reason the driver is pointing IN when 
no command is present is due to the "data valid 
after WRITE" requirements 
of the 8255As. The 


8255A requires that data remain on its data lines 
for 30 ns after the WRITE command (WR at the 
8255A)is removed. This requiremen t will be met if 
the direction of the 8287 drivers is not switched 


when the MULTIBUS IOWCI 
signal is removed 


(WRTI 
could have been used to steer the 8287 


instead of RD); and if the capacitance 
of the on- 


board data bus lines is sufficient to hold the data 
values on the bus after the 8287 OE signal and the 
8255A PPI WRTI signal go inactive. The on-board 
data bus may easily be designed such that the 
capacitance of the lines is sufficient to meet the 30 
ns data hold time requirement. 
In addition, the 


current leakage of all devices connected to the on- 
board bus must be kept small to meet the 30ns data 
hold time requirement. 


The 8-bit version of this design example uses only 
one 8287 instead of the three required by the 8/16- 
bit version. The logic required to control the swap 
byte buffer is also not necessary. 
The chip select 


signal used for the 8287 is the BD ENBLI 
signal. 


Control 
Signals 
- 
The MULTIBUS 
control 


signals 
used by this slave design example are 


IORCI, 
IOWCI, 
and XACK/. 
IORCI 
andlOWCI 


are qualified by the BASE ADR SELECT I signal 
to form the signals RD and WRT. RD and WRT 
are used to drive the interrupt logic, the PPI logic 
and the XACKI 
(transfer acknowledge) logic. 


For the XACKI 
logic RD and WRT are ORed to 


form the BD ENBLI 
signal which is inverted and 


used to drive the CLEAR pin of a shift register. 
When the slave board is not being accessed, the 
CLEAR pin of the shift register will be low (BD 
ENBLI 
is high). This causes the shift register to 


remain cleared and all outputs ofthe shift register 
will be low. When the slave board is accessed, the 
CLEAR pin will be high, and the A and B inputs 
(which are high) will be clocked to the output pins 
by CCLK/. 
To select a delay for the XACKI 
signal, 


a jumper must be installed from one of the shift 
register output pins to the 8089 tri-state driver. 
Each of the shift register output pins select an 
integer multiple of CCLKI 
periods for the signal 


delay. Since the CCLKI 
signal is asynchronous, 


the actual delay selected may only be specified 
with a tolerance of one CCLKI 
period. 
In this 


example 
a delay of 3 - 4 CCLKI 
periods was 


selected; with a CCLKI 
period of 100 ns, the 


XACKI 
delay would occur somewhere within the 


range of 300 - 400 ns from the time when the 
CLEAR signal goes high. 


The control signal logic used in the 8-bit version of 
the slave design example is identical to the logic 
used in the 8/16-bit version. 


Interrupt 
Logic - 
The interrupt 
logic uses a 


74S74 flip-flop to latch an asynchronous 
interrupt 
request from some external logic. The Q output 
of the INTERRUPT REQUEST LATCH is output 
through 
an open collector gate 
to one of the 
MULTIBUS 
interrupt 
lines. 
The state 
of the 
INTERRUPT 
REQUEST LATCH is transferred 


to the INTERRUPT 
STATUS LATCH when a 
read command 
is performed on 110 port BASE 
ADDRESS+O (E30 for the jumper configuration 
shown). The Q output of INTERRUPT STATUS 
LATCH is used to drive data line DO of the on- 
board data bus by using an 8089 tri-state driver. 
If a user program performs an INPUT from 110 
port E30, data bit 0 will be set to 1 if the INTER- 
RUPT REQUEST LATCH is set. 


The purpose of INTERRUPT STATUS LATCH is 
to minimize the possibility of the asynchronous 
interrupt 
occuring while the interrupt 
status 
is 
being read by a bus master. 
If the latch was not 
included in the design and an asynchronous 
inter- 
rupt 
did occur while a bus master 
is reading 
MULTIBUS data line DATOI, a data buffer on the 
master 
could go into a meta-stable 
state. 
By 


adding 
the extra latch, which is clocked by the 
10RDI command for 110 port E30, the possibility 
of data line DATOI changing during a bus master 
read operation is eliminated. 


The INTERRUPT 
REQUEST LATCH is cleared 


when a user program performs an OUTPUT to 1/0 
port E30. 


This 
interrupt 
structure 
assumes 
that 
several 


interrupt sources may exist on the same MULTI- 
BUS interrupt line (for example, INT3/). When the 
MULTIBUS master gets interrupted, it must poll 
the possible sources of the interrupt received and 
after determining 
the source of the interrupt, 
it 
must clear the INTERRUPT REQUEST LATCH 
for that particular 
interrupt source. 


The interrupt 
logic for the 8-bit version of the 
design example is identical to the interrupt logic of 
the 8/I6-bit version of the design example. 


PPI Operation - Two 8255A Parallel Peripheral 
Interface 
(PPI) devices are shown interfaced 
to 


the slave design example logic. One PPI is con- 
nected to the on-board data bus lines DO- D7 and 
is addressed 
with the even 110 port addresses 
E38, E3A, E3C, and E3E. 
The second PPI is 


connected to data bus lines D8 - DF and is address- 
ed with the odd 110 port addresses 
E39, E3B, 


E3D, and E3F. The even or odd 110 port selection 
is controlled by using the ADRO address line in 
the chip select term of the PPls. 
In addition, the 


odd PPI 
(All) 
is selected when the BHENBL 
term is high. 
This occurs when the MULTIBUS 


signal 
BHENI 
is low indicating 
that 
a word 
(I6-bit) 110 instruction 
is being executed. 
When 
a word 110 instruction is executed, both PPls will 
perform the 110 operation specified. 


The specifications 
of the 8255A device state that 


the address lines AO and Al and the chip select 
lines must be stable before the RD or WR lines are 
activated. 
The MULTIBUS specification address 


set-up time of 50 ns and the short gate propagation 
delays in this design assure that the address lines 
are stable before RD or WR are active. 


The data 
hold requirements 
of the 8255A were 
discussed in a previous section. The 8255A speci- 
fication states that data will be stable on the data 
bus lines a maximum 
of 250 ns after a READ 
command. 
This specification was used to select 


the delay for the XACKI 
signal. 


The PPI operation 
for the 8-bit version 
of the 


design example is slightly different than that used 
for the 8/I6-bit version. The chip select signal for 
the bottom PPI does not use the BHENBL term 
since I6-bit data transfers are not possible with an 
8-bit 110 slave board. 
Also, the chip select and 
address signals have been swapped so the top PPI 
occupies 110 address 
range 
X8 - XB, and the 


bottom PPI occupies 110 address range XC-XF (X 
is the base address 
of the 8-bit version). 
This 


swapping of the address lines was not necessary; 
however, it was thought to be more convenient to 
access the PPls in two groups of 4 contiguous I/O 
port addresses. 


This application note has shown the structure of 
the Intel MULTI BUS system bus. The structure 
supports a wide range of system modules from the 
Intel OEM Microcomputer Systems product line 
that can be extended with the addition 
of user 


designed 
modules. 
Because the user designed 


modules are no doubt unique to particular applica- 
tions, a goal of this application 
note has been to 


describe in detail the singular common element - 
the 
bus 
interface. 
Material 
has 
also 
been 


presented to assist the systems designer to under- 
standing 
the 
bus functions 
so that 
successful 


systems integration 
can be achieved. 


Appendix 


APPENDIX 
A - 
MULTIBUS@ PIN 


ASSIGNMENTS 
22 


APPENDIX 
B - 
BUS TIMING 


SPECIFICATIONS 
24 


APPENDIX 
C - 
BUS DRIVERS, 


RECEIVERS, 
AND TERMINATIONS 
26 


APPENDIX 
D - 
BUS POWER SUPPLY 


SPECIFICATIONS 
28 


APPENDIX 
E - 
MECHANICAL 


SPECIFICATIONS 
29 


APPENDIX 
F - 
MULTlBUS@ SLAVE 


DESIGN EXAMPLE 
SCHEMATIC 


8/16-BIT 
VERSION 
31 


APPENDIX 
G -"MULTIBUS'" 
SLAVE 


DESIGN EXAMPLE 
SCHEMATIC 


8-BIT VERSION 
33 


APPENDIX 
A 


PIN ASSIGNMENT 
OF BUS SIGNALS 
ON MULTIBUS@ 
BOARD 
P1 CONNECTOR 


(COMPONENT 
SIDE) 
(CIRCUIT SIDE) 


PIN 
MNEMONIC 
DESCRIPTION 
PIN 
MNEMONIC 
DESCRIPTION 


1 
GND 
Signal GND 
2 
GND 
Signal 
GND 
3 
+5V 
+ 5Vdc 
4 
+5V 
+5Vdc 
POWER 
5 
+5V 
+5Vdc 
6 
+5V 
+5Vdc 
SUPPLIES 
7 
+12V 
+12Vdc 
8 
+12V 
+12Vdc 
9 
-5V 
-5Vdc 
10 
-5V 
-5Vdc 
11 
GND 
Signal GND 
12 
GND 
Signal GND 


13 
BCLKI 
Bus Clock 
14 
INIT/ 
Initialize 
15 
BPRNI 
Bus Pri. In 
16 
BPROI 
Bus Pri. Out 
BUS 
17 
BUSYI 
Bus Busy 
18 
BREOI 
Bus Request 


CONTROLS 
19 
MRDCI 
Mem ReadCmd 
20 
MWTCI 
Mem Write Cmd 
21 
10RCI 
110 Read Cmd 
22 
10WCI 
110 Write Cmd 
23 
XACKI 
XFER Acknowledge 
24 
INH11 
Inhibit1 
disable 
RAM 


BUS 
25 
Reserved 
26 
INH21 
Inhibit 2 disable 
PROM or ROM 


CONTROLS 
?7 
BHENI 
Byte High Enable 
28 
AD101 


AND 
29 
CBROI 
Common 
Bus Request 
30 
AD111 
Address 


ADDRESS 
31 
CCLKI 
Constant 
Clk 
32 
AD121 
Bus 
33 
INTAI 
Intr Acknowledge 
34 
AD131 


35 
INT61 
Parallel 
36 
INT71 
Parallel 


INTERRUPTS 
37 
INT41 
Interrupt 
38 
INT51 
Interrupt 
39 
INT21 
Requests 
40 
INTJI 
Requests 
41 
INTOI 
42 
INT11 


43 
ADREI 
44 
ADRFI 
45 
ADRCI 
46 
ADRDI 


47 
ADRAI 
Address 
48 
ADRB/ 
Address 


ADDRESS 
49 
ADR81 
Bus 
50 
ADR91 
Bus 
51 
ADR61 
52 
ADR7I 


53 
ADR41 
54 
ADR51 


55 
ADR21 
56 
ADR31 


57 
ADROI 
58 
ADR11 


59 
DATEI 
60 
DATFI 
61 
DATCI 
62 
DATDI 


63 
DATAl 
Data 
64 
DATBI 
Data 


DATA 
65 
DAT81 
Bus 
66 
DAT91 
Bus 
67 
DAT61 
68 
DAT71 


69 
DAT41 
70 
DAT51 
71 
DAT21 
72 
DATJI 


73 
DATOI 
74 
DAT11 


75 
GND 
Signal GND 
76 
GND 
Signal GND 
77 
Reserved 
78 
Reserved 
POWER 
79 
-12V 
-12Vdc 
80 
-12V 
-12Vdc 
SUPPLIES 
81 
+5V 
+ 5Vdc 
82 
+5V 
+5Vdc 
83 
+5V 
+ 5Vdc 
84 
+5V 
+5Vdc 
85 
GND 
Signal GND 
86 
GND 
Signal GND 


All 
Mnemonics 
Cl Intel 
Corporation 
1978 


APPENDIX 
A (Continued) 


P2 CONNECTOR 
PIN ASSIGNMENT 
OF OPTIONAL 
BUS SIGNALS 


(COMPONENT 
SIDE) 
(CIRCUIT SIDE) 


PIN 
MNEMONIC 
DESCRIPTION 
PIN 
MNEMONIC 
DESCRIPTION 


1 
GND 
Signal GND 
2 
GND 
Signal GND 


3 
5 VB 
+5V Battery 
4 
5 VB 
+5V Battery 
5 
Reserved 
6 
vCCPP 
+ 5V Pulsed Power 


7 
-5 VB 
-5V Battery 
8 
-5 VB 
-5V Battery 
9 
Reserved 
10 
Reserved 
11 
12 VB 
+12V Battery 
12 
12 VB 
+ 12V Battery 


13 
PFSRJ 
Power Fail Sense Reset 
14 
Reserved 
15 
-12 VB 
-12V Battery 
16 
-12 VB 
-12V Battery 
17 
PFSNJ 
Power Fail Sense 
18 
ACLO 
AC Low 
19 
PFINJ 
Power Fail Interrupt 
20 
MPROJ 
Memory Protect 
21 
GND 
Signal GND 
22 
GND 
Signal GND 
23 
+15V 
+15V 
24 
+15V 
+15V 
25 
-15V 
-15V 
26 
-15V 
-15V 
27 
PAR11 
Parity 1 
28 
HALTJ 
Bus Master HAL T 
29 
PAR21 
Parity 2 
30 
WAITI 
Bus Master WAIT STATE 
31 
1\ 
32 
ALE 
Bus Master ALE 
33 
34 
Reserved 
35 
36 
Reserved 
37 
38 
AUX RESETI 
Reset switch 
39 
40 
, 


40 
42 
43 
Reserved 
44 
45 
46 
47 
48 
49 
50 
Reserved 
51 
52 
53 
54 
55 
56 
57 
56 
59 
60 


Notes: 


1. PFIN, on slave modules, 
if possible, 
should have the option of connecting 
to INTOJon P1. 
2. All undefined 
pins are reserved 
for future use. 
All Mnemonics 
III Intel Corporation 
1978 


APPENDIX 
B 


BUS TIMING 
SPECIFICATIONS 
SUMMARY 


Parameter 
Description 
Minimum 
Maximum 
Units 


tBCY 
Bus Clock Period 
100 
DC 
ns 


tBW 
Bus Clock Width 
0.35 tBCY 
065 tBCY 


,Nul Re~lrlt:teul 


tSKEW 
BCLKlskew 
3 
ns 


tpD 
Standard 
Bus 
3 
Propagation 
Delay 


tAS 
Address 
Set-Up Time 
50 
ns 
(at Slave Board) 


tDS 
Write Data Set 
50 
ns 
Up Time 


tAH 
Address 
Hold Time 
50 
ns 


tDHW 
Write Data Hold Time 
50 
ns 


tDXL 
Read Data Set 
a 
ns 


Up Time To XACK 


tDHR 
Read Data Hold Time 
a 
65 
ns 


tXAH 
Acknowledge 
Hold 
a 
65 
ns 


Time 


tXACK 
Acknowledge 
Time 
a 
B 
"$ 


tCMD 
Command 
Pulse 
100 
9 0 
ns 
Width 


tlD 
Inhibit Delay 
a 
100 
ns 
(Recommend 
< 100 ns) 


tXACKA 
Acknowledge 
Time of 
tIAD+ 
50 ns 
1,00 


of an Inhibited 
Slave 


tXACKB 
Acknowledge 
Time of 
15 
B 
!J.s 


an Inhibiting 
Slave 


tlAD 
Acknowledge 
Disable 
a 
100 
ns 
from Inhibit (An 
(arbitrary) 
Internal parameter 
on 
an inhibited 
slave; 
used to determine 
tXACKA Min.) 


IAIZ 
Address 
tu Inhibits 
ns 


High Delay 


tlNTA 
INTAI Width 
250 
ns 


tCSEP 
Command 
Separation 
100 
ns 


APPENDIX 
B (Continued) 


BUS TIMING 
SPECIFICATIONS 
SUMMARY 


Parameter 
Description 
Minimum 
Maximum 
Units 


tBREOL 
IBCLKI 
to BREOI 
0 
35 
ns 


Low Delay 


tBREOH 
IBCLKI 
to BREOI 
0 
35 
ns 
High Delay 


tBPRNS 
BPRNI to IBCLKI 
22 
ns 


Setup Time 


tBUSY 
BUSY / delay 
0 
70 
ns 
from IBCLKI 


tBUSYS 
BUSY I to IBCLKI 
25 
ns 
Setup Time 


tBPRO 
IBCLKI 
to BPROI 
0 
40 
ns 


(CLK to Priority 
Out) 


tBPRNO 
BPRNI to BPROI 
0 
30 
ns 


(Priority 
In to Out) 


tCBRO 
IBCLKI 
to CBRO/ 
0 
60 
ns 


(CLKto Common 
Bus Request) 


tCBROS 
CBROI to IBCLK/ 
35 
ns 
Setup Time 


lXCD 
XACKI to Command I 
I' 
1500 
ns 


Delay 


tBSYO 
CBRQII and BUSYII 
- 
12 
"s 


to BUSYII 


tCCY 
C-clock Period 
100 
110 
ns 


tcw 
C-clock Width 
0.35 tCCY 
0.65 tCCY 
ns 


tlNIT 
INIT/Width 
5 
ms 


tiN ITS 
INITI to MPROI 
100 
ns 


Setup Time 


tpBD 
Power Backup 
0 
200 
ns 


Logic Delay 


tPFINW 
PFIN/ Width 
2.5 
ms 


tMPRO 
MPROI Delay 
2.0 
2.5 
ms 


tACLOW 
ACLO/ Width 
3.0 
ms 


tPFSRW 
PFSRI Width 
100 
ns 


troUT 
Timeout 
Delay 
5 
~(DC) 
ms 


lOCH 
D.C. Power Supply 
30 
ms 


Hold from ALCOI 


tDCS 
o C. Power Supply 
5 
ms 


Setup to ACLOI 


APPENDIX 
C 


BUS DRIVERS, 
RECEIVERS, 
AND 
TERMINATIONS 


Driver 
1,3 
Receiver 
2,3 
Termination 


BUI Slgnlll 
Locltlon 
Type 
10L 
10H 
Co 
Location 
IlL 
IIH 
CI 
location 
Type 
R 
Units 


M1nma 
Mln_" 
MUpf 
Maxma 
M.x~1 MUpf 


OATO/-OATFI 
Masters 
TAl 
16 
-2000 
300 
Masters 
-08 
125 
18 
1 place, 
Pullup 
2.2 
KQ 


(16 lines) 
and Slaves 
and Slaves 


AOAO/-AOAB/, 
Masters 
TAl 
16 
-2000 
300 
Slaves 
-0,8 
125 
18 
1 place 
Pullup 
22 
KQ 


BHENI 
(21l1nesl 


MAOCI,MWTC/ 
Masters 
TAl 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


{Memory, 
memory- 
mapped 
1/01 


10AC/,IOWCI 
Masters 
TAl 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(1/01 


XACKI 
Slaves 
TAl 
32 
-2000 
300 
Masters 
-2 
125 
18 
1 place 
Pullup 
510 
Q 


INH1/,INH21 
Inhibiting 
OC 
16 
- 
300 
Inhibited 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


Slaves 
Slaves 
(AAM, 
PAOM, 


AOM, Memory- 
Mapped 
1/0) 


BCLKI 
1 place 
TTL 
48 
-3000 
300 
Master 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 


(Masler 
us) 
board 
ToGNO 
330 
Q 


BAEQI 
Each 
TTL 
5 
-200 
60 
Central 
2 
50 
18 
Central 
Pullup 
1 
KQ 


Master 
Priority 
Priority 


Module 
Module 
(not req) 


SPAO/ 
Each 
TTL 
5 
-200 
60 
Next Masler 
-1 6 
50 
18 
(not 
reQ) 


Master 
In Senal 
Priority 
Chain at 
Its SPAN/ 


SPAN/ 
Parallel 
TTL 
5 
-200 
300 
Master 
-4 
100 
Inot req) 


Central 
Priority 
Module 
Senal:Prev 
Masters 
SPAOI 


BUSY 
CBRQ 
All Masters 
OC 
20 
- 
300 
All Masters 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


IN IT 
Master, 
OC 
32 
- 
300 
All 
-2 
50 
18 
1 place 
Pullup 
22 
KQ 


CCLK 
1 place 
TTL 
48 
-3000 
300 
Any 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 


board 
To GNO 
330 
Q 


INTAI 
Masters 
TAl 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(Interrupting 


110) 


INTO/-INTI/ 
Slaves 
OC 
16 
- 
300 
Masters 
-16 
40 
18 
1 place 
Pullup 
1 
KQ 


(8lmesl 


PFSAI 
User"s Fron 
TTL 
16 
-400 
300 
Slaves. 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Panel? 
Masters 


PFSNI 
Power Back 
TTL 
16 
-400 
300 
Masters 
-1 6 
40 
18 
1 place 
Pullup 
1 
KQ 


Up Unit 


ACLO 
Power 
OC 
16 
-400 
300 
Slaves. 
-1 6 
40 
18 
1 place 
Pullup 
1 
KQ 


Supply 
Masters 


PFINI 
Power Back· 
OC 
16 
-400 
300 
Masters 
-1 6 
40 
18 
1 place 
Pullup 
1 
KQ 


up Unit 


MPAOI 
Power Back· 
TTL 
16 
-400 
300 
Slaves 
-, .6 
40 
18 
I place 
Pullup 
1 
KQ 


Up Unit 
Masters 


APPENDIX 
C (Continued) 


BUS DRIVERS, 
RECEIVERS, 
AND 
TERMINATIONS 


Driver 
1,3 
Receiver 
2,3 
Termination 


Bus Signals 
location 
Type 
IOl 
IOH 
Co 
Location 
III 
IIH 
C, 
Location 
Type 
R 
Units 


Minma 
Min",8 
MUpl 
Maxma 
Maxj.oI8 
MUpf 


Aux Resell 
User's 
Switch 
- 
- 
- 
Masters 
-2 
50 
18 
None 
Front 
toGND 
Panel? 
INoie SI 


Notes: 


1 
Driver 
Requirements 


10H 
= 
High Output Current Dnve 
IOl 
= 
Low Output 
Current 
Drive 


Co 
= Capacitance 
Drive Capability 
TRI 
= 3·5tate Drive 


OC 
= Open Collector 
Driver 


TTl 
= Totem-pole 
Driver 


2 
Receiver 
Requirements 


IIH 
= High Input Current 
load 
III 
:= Low Input Current 
Load 


C, 
= 
Caoacitive 
Load 


3. 
TTllow 
state 
must 
be.:> -0.5v 
but 
~0.8v 
at the 
receivers 


TTL 
high 
state 
must 
be2 
2.Ov but,:: 
5.5v at the 
receivers 


4. 
For the 
iSSC 
80/10 
and 
the 
iSSC 
80/10A 
use only 
a lK 
pUll-up 
resistor 
to +5v lor 
SCLKI 
and 
CCLKI 
termination. 


5 
Recommend 
a 47H resistor 
in series 
with 
switch. 


APPENDIX D 


BUS POWER SPECIFICATIONS 


, 
Standard (P1) 
Optional (P2) 


Analog Power 
Battery Power Backup 


Ground 
+5 
+ 12 
-12 
+15 
-15 
+5 
+12 
-12 
-5 


Mnemonic 
GND 
+5V 
+ 12V 
-12V 
+ 15V 
-15V 
+5B 
+ 12B 
-12B 
-5B 


Bus Pins 
P1+ 1,2, 
P1+ 3,4, 
P1+ 7,8 
P1+ 79, P2+ 23, 
P2+ 25, 
P2+ 3,4, 
P2+ 11, 
P2+15, 
P2-7,8 


11,12, 
5,6,81, 
80 
24 
26 
5,6 
12 
16 
75,76 
82,83, 


85,86 
84 


Nominal Output 
Ref. 
+5.0V 
+ 12.0V 
-12.0V 
+ 15.0V 
-15.0V 
+5.0V 
+ 12.0V 
-12.0V 
-5.0V 


Tolerance from 
Nominal' 
Ref. 
±5% 
±5% 
±5% 
±3% 
±3% 
±5% 
±5% 
±5% 
±5% 


Ripple 
(Pk-Pk)' 
Ref. 
50 mV 
50 mV 
50 mV 
10 mV 
10 mV 
50 mV 
50 mV 
50 mV 
50 mV 


Transient 
Response 
5001'5 
5001'5 
5001'5 
1001's 
1001's 
5001'5 
5001'5 
5001'5 
5001'5 
Time' 


Transient 
Deviation' 
±10% 
± 10% 
±10% 
± 10% 
±10% 
±10% 
± 10% 
± 10% 
± 10% 


NOTES: 


1. Tolerance 
is worst case, including 
initial voltage 
setting 
line and load effects 
of power source, temperature 
drift, and any additional 
steady 
state infJu~nces. 


2. As measured 
over any bandwidth 
not to exceed 0 to 500 kHz. 


3. As measured 
from the start of a load change to the time an output 
recovers 
within 
± 0.1 % of final Yoltage. 


4. Measured 
as the peak deviation 
from the initial 
voltage. 


APPENDIX 
E 


MECHANICAL 
SPECIFICATIONS 


»,'. 
BOARO 
THICI(NESS 


~ 
MUL TIBUS~ 
CONNECTOR: 
8&PIN, 
0.156 
SPACING 


[;> 


i]'25 


5950 
!;0003 


."·J"'." 


~J~ 


B> 
EJECTOR 
TYPE 
SCAJIlBE 
_5203 


BUS 
DRIVERS 
AND 
RECEIVERS 
SHOULD 
BE LOCATEO 
AS CLOSE 
AS POSSIBLE 
TO 


THEIR 
RESPECTIVE 
MUL TIBUS 
PIN 
CONNECTIONS 
• 


APPENDIX F 


MULTIBUS® SLAVE DESIGN EXAMPLE SCHEMATIC 
8/16·BIT VERSION 


AP-28A 
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APPENDIX 
B' 


BUS TIMING 
SPECIFICATIONS 
SUMMARY 


Parameter 
Description 
Minimum 
Maximum 
Units 


tBCY 
Bus Clock Period 
100 
D.C. 
ns 


tBW 
Bus Clock Width 
035 tBCY 
0.65 tBCY 
(Not Restricted) 


tSKEW 
BCLK/skew 
3 
ns 
tpD 
Standard 
Bus 
3 
Propagation 
Delay 


tAS 
Address 
Set-Up Time 
50 
ns 
(at Slave Board) 


tDS 
Write Data Set 
50 
ns 


Up Time 


tAH 
Address 
Hold Time 
50 
ns 


tDHW 
Write Data Hold Time 
50 
ns 


tDXL 
Read Data Set 
a 
ns 


Up Time To XACK 


tDHR 
Read Data Hold Time 
a 
65 
ns 


tXAH 
Acknowledge 
Hold 
a 
65 
ns 


Time 


tXACK 
Acknowledge 
Time 
a 
8 
~s 


tCMD 
Command 
Pulse 
100 
95 
ns 


Width 


tlD 
Inhibit Delay 
a 
100 
ns 


(Recommend 
< 100 ns) 


tXACKA 
Acknowledge 
Time of 
tIAD+ 50 ns 
1500 


of an Inhibited 
Slave 


tXACKB 
Acknowledge 
Time of 
15 
8 
)J.s 


an Inhibiting 
Slave 


tlAD 
Acknowledge 
Disable 
a 
100 
ns 


from Inhibit (An 
(arbitrary) 


internal 
parameter 
on 
an inhibited 
slave; 


used to determine 
tXACKA Min.) 


tAIZ 
Address to Inhibits 
100 
, 
ns 


High Delay 


tlNTA 
INTAI Width 
250 
ns 
tCSEP 
Command 
Separation 
100 
ns 


APPENDIX B (Continued) 


BUS TIMING SPECIFICATIONS 
SUMMARY 


Parameter 
Description 
Minimum 
Maximum 
Units 


tBREOL 
IBCLK/to 
BREOI 
0 
35 
ns 
Low Delay 


tBREOH 
IBCLKI 
to BREOI 
1l 
35 
ns 


High Delay 


tBPRNS 
BPRNlto 
IBCLKI 
22 
ns 


Setup Time 


tBUSY 
BUSYI delay 
0 
70 
ns 


from IBCLKI 


tBUSYS 
BUSY I to IBCLKI 
25 
ns 
Setup Time 


tBPRO 
IBCLKI 
to BPROI 
0 
40 
ns 
(CLK to Priority 
Out) 


tBPRNO 
BPf'1Nlto 
BPROI 
0 
30 
ns 
(Priority 
In to Out) 


tCBRO 
IBCLKI 
to CBROI 
0 
60 
ns 
(CLKto Common 
Bus Request) 


tCBROS 
CBROI to IBCLKI 
35 
ns 
Setup Time 


tXCD 
XACKI to Command I 
a 
1500 
ns 


Delay 


tBSYO 
CBRQII and BUSYII 
- 
12 
I'S 


to BUSY" 


tCCY 
C-clock Period 
100 
110 
ns 


tcw 
C-clock Width 
0.35 tCCY 
0.65 tCCY 
ns 


tiN IT 
INITIWidth 
5 
ms 


tiN ITS 
INITI to MPROI 
100 
ns 
Setup Time 


tpBD 
Power Backup 
a 
200 
ns 
Logic Delay 


tPFINW 
PFINI Width 
2.5 
. 
ms 


tMPRO 
MPROI Delay 
2.0 
25 
ms 


tACLOW 
ACLOI Width 
3.0 
ms 


tPFSRW 
PFSRI Width 
100 
ns 


tTOUT 
Timeout 
Delay 
5 
00 (DC) 
ms 


IDCH 
D.C. Power Supply 
30 
ms 
Hold from ALCOI 


tDCS 
D.C. Power Supply 
5 
ms 
Setup to ACLO I 


APPENDIX 
C 


BUS 
DRIVERS, 
RECEIVERS, 
AND 
TERMINATIONS 


Drl.er 
1,3 
Recel.er 
2,3 
Termin.tion 


Bus Slgnlls 
LOClllon 
Type 
10L 
10H 
Co 
Locillon 
IlL 
IIH 
CI 
LOClllon 
Type 
R 
Units 


Mlnml 
Mln~1 
MUpf 
M1Xml 
MU~I 
MUpl 


DATO/-DATFI 
Masters 
TRI 
16 
-2000 
300 
Masters 
-0.8 
125 
18 
1 place 
Pullup 
2.2 
KQ 


(16Imes) 
and Slaves 
and Slaves 


ADRO/-ADRB/, 
Masters 
TRI 
16 
-2000 
300 
Slaves 
-0.8 
125 
18 
1 place 
Pull up 
2.2 
KQ 


BHENI 
(21 lines) 


MRDC/,MWTCI 
Masters 
TRI 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(Memory; 
memory- 
mapped 
110) 


10RC/,tOWCI 
Masters 
TRI 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(1/0) 


XACKI 
Slaves 
TAl 
32 
-2000 
300 
Masters 
-2 
125 
18 
1 place 
Pullup 
510 
Q 


INH11,INH21 
Inhibiting 
OC 
16 
- 
300 
Inhibited 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


Slaves 
Slaves 
(RAM, PROM, 
ROM, Memory- 
Mapped 
110) 


BCLKI 
1 place 
TTL 
48 
-3000 
300 
Master 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 


(Master 
us) 
board 
ToGND 
330 
Q 


BREQI 
Each 
TTL 
5 
-200 
60 
Central 
2 
50 
18 
Central 
Pullup 
1 
KQ 


Master 
Priority 
Priority 


Module 
Module 
(not req) 


BPRO! 
Each 
TTL 
5 
-200 
60 
Next Master 
-1 6 
50 
18 
(not req) 


Master 
in Serial 
Prionty 
Chain at 
Its BPRNI 


BPRN! 
Parallel: 
TTL 
5 
-200 
300 
Master 
-4 
lOa 
Inot reql 


Central 
Priority 
Module 
Serial:Prev 
Masters 
BPRO! - 
BUSYI, 
CBRQ 
All Maslers 
O.C. 
20 
- 
300 
All Masters 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


INITI 
Master, 
OC. 
32 
- 
300 
All 
-2 
50 
18 
1 place 
Pullup 
22 
KQ 


CCLKI 
1 place 
TTL 
48 
-3000 
300 
Any 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 
board 
ToGND 
330 
Q 


INTAI 
Masters 
TAl 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(Interrupting 
I/O) 


INTOI-INn! 
Slaves 
OC 
16 
- 
300 
Masters 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


(811ne51 


PFSRI 
User's 
Fron 
TTL 
16 
-400 
300 
Slaves, 
-16 
40 
18 
1 place 
Pullup 
1 
KQ 


Panel? 
Masters 


PFSNI 
Power 
Back 
TTL 
16 
-400 
300 
Masters 
-1.6 
40 
18 
I place 
Pullup 
1 
KQ 


Up Unit 


ACLO 
Power 
O.C. 
16 
-400 
300 
Slaves, 
-1 6 
40 
18 
1 place 
Pullup 
1 
KQ 


Supply 
Masters 


PFINI 
Power 
Back· 
OC 
16 
-400 
300 
Masters 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Up Unit 


MPROI 
Power 
Back- 
TTL 
16 
-400 
300 
Slaves 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Up Unit 
Masters 


APPENDIX C (Continued) 


BUS DRIVERS, RECEIVERS, AND TERMINATIONS 


DriYerl,3 
Receiyer 2,3 
Termination 
- 
Bus Signsis 
location 
Type 
IOL 
IOH 
Co 
Location 
IlL 
IIH 
C, 
location 
Type 
R Units 


M1nms Mln.s MUpl 
MI·ml 
MIX",. 
MUpl 


Aux Resetl 
User's 
Switch 
- 
- 
- 
Masters 
-2 
50 
18 
None 
Front 
toGND 
Panel? 
(Note 5) 


Notes: 


I. 
Driver 
Requirements 


I 


IOH 
= High Output Current Drive 


iOL 
= Low Oulput Current Drive 


Co 
= Capacilance Drive Capabilily 
TRI 
= 3-Stale Drive 


OC. 
= Open Collector Driver 
TTL 
:::: Totem-pole 
Driver 


2 
Receiver 
Requirements 


IIH 
= High Input Currenl load 
III 
= low Input Current Load 


C, 
= Capacitive Load 
3. TTl 
low state must be.2 -0.5v but,;. 0.8v at the receivers 
TTl 
high state must be2 
2.Ov but s:. 5.5v at the receivers 


4. For the iSSC 80/10 and the iSSC 801loA use only a lK pUll-Up resistor 
to +5v for SClKI 
and CClKI 
termination. 


5. Recommend 
a 4711 resistor 
in series with switch. 


APPENDIX D 


BUS POWER SPECIFICATIONS 


Standard (P1) 
Optional (P2) 


Analog Power 
Battery Power Backup 


Ground 
+5 
+12 
-12 
+ 15 
-15 
+5 
+ 12 
-12 
-5 


Mnemonic 
GND 
+5V 
+12V 
-12V 
+ 15V 
-15V 
+58 
+ 128 
-128 
-58 


8us Pins 
P1+ 1,2, 
P1+ 3,4, 
P1+ 7,8 
P1+ 79, 
P2+23, 
P2+25, 
P2+3,4, 
P2+ 11, 
P2 + 15, 
P2-7,8 
11,12, 
5,6,81, 
80 
24 
26 
5,6 
12 
16 
75,76 
82,83, 


85,86 
84 


Nominal Output 
Ref. 
+5.0V 
+ 12.0V 
- 12.0V 
+ 15.0V 
-15.0V 
+5.0V 
+ 12.0V 
-12.0V 
-5.0V 


Tolerance from 
Nominal' 
Ref. 
±5% 
±5% 
±5% 
±3% 
±3% 
±5% 
±5% 
±5% 
±5% 


Ripple 
(Pk-Pk)' 
Ref. 
50 mV 
50 mV 
50 mV 
10 mV 
10 mV 
50 mV 
50mV 
50 mV 
50mV 


Transient 
Response 
500l"s 
500l"s 
500 I"S 
100l"s 
100l"s 
500l"s 
500 I"S 
500 I"S 
500 I"S 
Time' 


Transient 
Deviation' 
± 10% 
±10% 
±10% 
± 10% 
± 10% 
±10% 
±10% 
±10% 
±10% 


NOTES: 


1. Tolerance 
is worst 
case, including 
initial 
voltage 
setting 
line and load effects 
of power source, 
temperature 
drift, 
and any additional 
steady 


state inllu~nces. 


2. As measured 
over any bandwidth 
not to exceed 
0 to 500 kHz. 


3. As measured 
from 
the start 
01 a load change 
to the time an output 
recovers 
within 
± 0.1 % of final 
voltage. 


4. 
Measured 
as the peak deviation 
from 
the initial 
voltage. 


APPENDIX 
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MECHANICAL 
SPECIFICATIONS 
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NOTES: 
[9 
BOARD 
THICKNESS: 
0.062 


[3> 
MUL TlBUS- 
CONNECTOR: 
86-PIN, 
0.156 
SPACING 


f9 
AUXILIARV CONNEClOR: 
&C.PlN, 
0.100 Sl'ACING 


B> 
EJECTOR 
TYPE: 
SCANBE 
.S20J 


BUS 
DRIVERS 
AND 
RECEIVERS 
SHOULD 
BE LOCATEO 
AS CLOSE 
AS POSSIBLE 
TO 
THEIR 
RESPECTIVE 
MUL 1I8U5 
PIN 
CONNECTIONS 


6. 
BOARD SPACING: 
0.8 


COMPONENT 
HEIGHT: 
0.• 


APPLICATION 
NOTE 


During the past twenty years, the automated 
process 
control industry has matured significantly. This is due to 
the introduction of the digital computer as an element of 
the control system. At the beginning of this period, the 
use of the digital computer was limited to a supervisory 
status in which the actual control was performed 
by 
various combinations of relay, analog, and pneumatic 
systems. Today, systems are off-the-shelf digital hard- 
ware and software to perform all the control applications. 
Indeed, the use of the hardware/software 
combination 


has opened entirely new areas of control applications. 


The significant increase in computer capabilities and the 
corresponding reduction in size has been accompanied 
by a substantial drop in cost. This has led to a strong in- 
centive for users to employ computers in totally new ap- 
plication areas which have resulted from this change in 
economics. Twenty years ago, few computer control 
projects were initiated and those which were could only 
be justified economically in terms of control systems 
which controlled 
upwards 
of 
100 loops. 
Today, 
a 


microcomputer system can be justified for a small pro- 
cess which contains as few as 3 or 4 control loops. 


Today, the control system engineer's decision is not so 
much an economic justification of a digital process as it 
is a choice of whether to use a single or a multiple 
microcomputer based design. 


The trend toward the use of digital technology in the 
control world has been driven, in part, by the products 
which have been introduced 
into the marketplace by 
Intel Corporation. 
A recently announced product, the 


iSBC 88/40 Measurement and Control Computer, is in- 
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technologies into varied control applications and is the 
subject of this application note. Its architecture is well 
suited for both single microcomputer 
and multicom- 


puting environments. The board is also easily adapted to 
a wide variety of input/output 
configurations 
through 


on-board facilities and iSBX MULTIMODULE 
expan- 


sion boards. 


Generalized Computer Application Areas 


Those applications in which computers are finding ac- 
ceptance can generally be broken down into two broad 
areas. The first involves the acquisition and manipula- 
tion of process data by the computer, and is sometimes 
referred to as being a class of passive applications. The 
second, 
known as active systems, also involves the 


manipulation 
of the process itself. The systems in the 


latter class also provide various degrees of passive data 
manipulation. 


~ 
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inter . 


At first glance, the area of passive computer applica- 
tions seems to have little or nothing to do with process 
control; however, many computer design projects are 
being split into two phases. One phase is to characterize 
the process and the second is concerned with the actual 
control system. Many designs never move from phase 
one and are used as data acquisition systems. 


The majority 
of passive systems involve measuring 


physical parameters 
of the process application. 
Ex- 
amples are the measurement of pressure, temperature, 
flow, force, and level. Most transducers associated with 
these physical parameters 
provide 
an analog signal 


which is proportional 
to the physical property being 


sensed. Thus, the ability to measure analog voltages is a 
requirement of process control systems, both active and 
passive. 


The iSBC 88/40 Measurement and Control Computer is 
ideally suited for these classes of systems because of the 
board's 
built-in analog to digital conversion circuitry. 
Each input channel (there are 16differential or 32 single- 
ended channels on the board) has its own programmable 
gain which can be software selected to provide full scale 
inputs ranging from 20 millivolts to 10 volts. The board 
is thus compatible 
with most commonly 
available 


transducer 
elements. 
Examples 
of typical 
interface 
drivers are given in later sections of this application 
note. 


Active applications 
must interact 
with the control 


system in order to manage the process. This normally in- 
volves the activation and movement of a mechanical ele- 
ment which is incorporated 
into the process loop. An 


amplifier and transducer 
are required to convert the 


electrical 
output 
of the controller 
into mechanical 


energy. The majority 
of these activators are electro- 


pneumatic, 
requiring both an electrical control signal 


(usually 4-20 milliamps) from the controller and an air 
supply for its internal pneumatic amplifier. Less com- 
mon, but still in substantial 
numbers, 
are activators 


which use either a frequency input control signal or step- 
ping motors. 


Again, the iSBC 88/40 Measurement and Control Com- 
puter provides features designed to allow easy interface 
to various control actuators. For those actuators using 
digital frequencies or stepping motors, the board has a 
parallel output capability to drive up to 24 digital lines. 
Pulse output signals can be routed from programmable 
timers/counters 
(to generate a variety of pulse type out- 
puts) to the external I/O devices. Analog actuators can 
be driven 
using 
the 
iSBX 
328 Analog 
Output 


MULTIMODULE 
Board. This board connects to the 


measurement 
and control computer using one of the 


three iSBX connectors on the iSBC 88/40 board. Each 


iSBX 328 board can generate up to 8 analog output 
signals, each of which can function in either a voltage or 
current (4-20 milliamps) output mode. 


VOLTAGE 
OR 


-CURRENT 
(4-20mA) 


8741A 
UPI 
FOR FIRMWARE 
OPERATIONS 


_______ 
SINGLE 
WIDE 


MULTI 
MODULE'" 
FORM 
FACTOR 


Figure 3. iSBX™ 328 Analog Output 


MULTIMODULE™ 
Board 


Computer Processing Capabilities 


The key to the rapid growth of digital computers in pro- 
cess control has been the flexibility offered by the soft- 
ware. The same hardware can be used in widely varying 
applications 
by allowing customization 
through 
soft- 


ware programmming. 
To be successful in the process 


control marketplace, a digital computer system must be 
designed in a manner which optimizes the hardware/ 
software relationships. 
The iSBC 88/40 Measurement 


and Control Computer does this well. 


A powerful instruction set is mandatory 
if operations 


are to be efficiently performed by the processor. An in- 
struction set optimized to perform business operations 
will perform poorly in an industrial process application. 
The processor used on the iSBC 88/40 board is the Intel 
iAPX 
88/10 
microprocessor. 
This third 
generation 


microprocesor is suitable for a wide spectrum of applica- 
tions. The large application domain is made possible by 
the processor's 
dual operating 
modes and built-in 


multiprocessing features. The iAPX 88/10 microproces- 
sor is from four to six times more powerful than the 
8080A microprocessor. 


The high performance of the iAPX 88/10 microproces- 
sor is realized by combining an internal data path with a 
pipelined architecture 
that allows instructions 
to be 


prefetched during spare bus cycles. Also contributing to 
performance 
is a compact 
instruction 
format 
that 


enables more instructions 
to be fetched in a given 


amount of time. 


Software for high-performance iAPX 88/10 processors 
need not be written in assembly language (although it 
certainly can be). The CPU is designed to provide direct 
hardware support 
for programs written -in high level 


languages such as Intel's PL/M-86. 
Because most high 


level languages store variables in memory, the instruc- 


inter 


tion set supports direct operation on memory operands, 
including operands on the stack. The hardware address- 
ing modes provide efficient implementations 
of based 


variables, arrays, arrays of structures and other high 
level language data constructs. Hardware multiplication 
and division of signed and unsigned binary numbers, as 
well as unpacked decimal numbers, is fully supported by 
the CPU. In all, about 300 forms of machine level in- 
structions are supported by the iAPX 88/10 processor. 


Memory Options 


A key design requirement for the iSBC 88/40 Measure- 
ment and Control Computer was to have the board sup- 
port a variety of memory types and capacities. The result 
is a product which can easily be configured to meet a 
wide range of process control application requirements. 


Program storage support for small to very large applica- 
tions is obtained through the board's ability to include 
EPROM storage capacities ranging up to 64K bytes. 
Maximum standard storage capacity is from 8K bytes 
(using 2716 EPROM devices) to 32K bytes (using the 
2764 EPROM). 
An optional 
EPROM 
expansion 


MULTIMODULE board can be mounted onto the iSBC 
88/40 board to double the memory storage capacities. 


Variables used in an application are usually stored in 
RAM memory. A standard on-board RAM capacitiy of 
4K bytes js included on the measurement and control 
computer. 
In order 
to efficiently 
support 
multi- 


computer system design, IK bytes of this memory is 
dual-ported. Dual-porting introduces a three bus system 
architecture 
to system design. An on-board local bus 
creates a data path between the iAPX 88/10 CPU and its 
local RAM. Data paths to RAM located on other iSBC 
boards are provided by the facilities of the MULTIBUS 
system bus. Finally, a third bus provides a gateway into 
the local RAM by other MULTIBUS single board com- 
puters or bus masters. If additional RAM is required, a 
small MULTIMODULE RAM expansion board can be 
attached to the iSBC 88/40 board to add 4K bytes of 
random access memory. 


Even more flexibility can be gained by using unneeded 
EPROM 
memory sockets. Because JEDEC standard 


24/28 pin sockets have been used, byte wide RAM 
modules can be inserted into areas of the EPROM 
memory space. The use of this RAM can considerably 
enhance the design of certain applications. The board 
capabilities are such that it is not necessary to have all 
devices residing in the EPROM sockets be of the same 
type or size. 


Many process control applications 
require the use of 
non-volatile memory for the storage of parameter lists 


and system setp~ints. Provision has been made on the 
iSBC 88/40 Measurement and Control Computer to ful- 
ly support Intel's new 2816 Electrically Eraseable and 
Programmable 
Read Only Memory (E2PROM). 
This 


device gives the user 2K bytes of memory. Depending on 
the application, up to eight devides (16K bytes) can be· 
used on the iSBC 88/40 board. The board includes all re- 
quired voltages and wave-shaping circuits to fully sup- 
port the use of the 2816. A byte of 2816 memory can be 
programmed in 16milliseconds. A subsequent section of 
this application note contains a comprehensive discus- 
sion of the operation of the board with the 2816. 


Using computers as an element in a control system leads 
to extensive arithmetic and mathematical functions. To 
be effective and attractive to the designer, a computer 
board must provide a wide range of mathematical capa- 
bilities. The iSBC 88/40 Measurement 
and Control 


Computer easily meets these needs with varying capa- 
bilities for hardware and software functions. 


Many applications 
are adequately 
handled using the 


hardware add/subtract 
and multiply/divide instructions 


of the on-board 
iAPX 
88/10 
processor. 
Functions 


needing integer arithmetic of varying precisions are easi- 
ly programmed using this facility. In some cases, more 
complex operations 
may require the use of software 


libraries to gain the required mathematical 
functions. 


The speed and instruction set of the CPU, in conjunc- 
tion with PL/M-86 
statements, 
make programmers 


comfortable with these operations. 


As processes become more involved and their control 
algorithms more complex, the need for the processor to 
support more precise numbers becomes important. The 
additional precision is usually obtained through the use 
of a floating point representation. 
Intel supplies several 


tools which simplify the implementation of systems re- 
quiring floating point operations. Complete support for 
the floating point numbers is provided as an integral 
part of the PL/M-86 compiler. Thus, variables can be 
specified as real numbers. The compiler will perform all 
numerical operations on these numbers in the floating 
point format. 
The data formats of all Intel floating 


p~int support conform to. the proposed IEEE Floating 
Point Standard, insuring highly accurate results. 


An important feature of the iAPX 88/10 processor is its 
ability to use a co-processor. The Intel 8087 is mounted 
on the iSBC 337 MULTIMODULE Numeric Data Pro- 
cessor to provide arithmetic and logical instruction ex- 
tensions to the 8086 and 8088 CPU's. The instruction set 
consists of arithmetic, transcendental, 
logical, trigono- 


metric, 
and exponential 
instructions 
which can all 


operate on seven different data types. In many cases, the 
use of this MULTIMODULE 
board 
results in two 
orders of magnitude performance enhancement over a 
software solution. This board is the subject of a subse- 
quent section of this application note. 
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Figure 4. iSBC™ 337 MULTIMODULE™ 
Numeric 
Data Processor 


APPLICATION 
EXA!\IIPLE 


The features of the iSBC 88/40 Measurement and Con- 
trol Computer can best be shown through an example. 
This application 
note describes the classical control 
system application of an agitated heating tank. Figure 5 
shows the prominent features of this process control ap- 
plications. The process consists of a storage vessel, a 
temperature sensor which measures the temperature of 
the fluid leaving the vessel, and a steam coil whose steam 
flow -is regulated by a proportional 
valve. A motor 
drives an agitator to insure the temperature of the tank 
remains homogeneous. 


STEAM 
CONTROL 
VALVE 


The passive portion of the application involves measur- 
ing the actual temperature of the fluid as it leaves the 
tank (and thus the temperature 
of all the fluid in the 


tank). If a control system is to be constructed which will 
control 
the temperature, 
an algorithm 
must be im- 
plemented which will provide control of the steam valve 
based upon the actual and the desired temperatures. 
This is the active portion of the application. 


The control 
algorithm 
selected to control 
the tank 
temperature 
must be capable 
of compensating 
for 
disturbances created by a variety of conditions. For ex- 
ample, the temperature can be affected by changes in 
steam temperature, input temperature of the fluid, out- 
put flow rate, ambient temperature, and the flow rate of 
steam through the steam coil. Our control system will 
have control of only one of the variables and will only 
monitor the output temperature. 
To gain a degree of 


stability under these conditions, 
a feedback 
control 
algorithm is required. Alternatively, a system could be 
implemented using a feed-forward 
control algorithm. 


Unfortunately, the latter technique would require exten- 
sive instrumentation 
of all possible variables 
which 
could cause a disturbance. 
A feedback control system 
can take corrective action regardless of the source of a 
disturbance. Its chief drawback is that no corrective ac- 
tion is taken until an error is actually detected and, if not 
"tuned" 
correctly, some oscillations can occur. 


Classical Controller Approaches 


Before proceeding with a discussion of how a control 
system can be implemented using single board com- 
puters, a short discussion of classical control system 
theory is in order. This material will provide a back- 
ground into the control algorithms which will be used as 
a basis for the digital control solution which will be 
developed. 


The classical controller for feedback systems uses the 
"three mode" or PID (Proportional, 
Integral, Deriva- 


tive) algorithm. In this system, the control output signal 
is a function of the error (the difference between the set- 
point and the measured system variable). A specific ap- 
plication will use some combination of one, two, or all 
three terms making up the control statement. 


Before continuing with the implementation of the con- 
trol algorithm on the iSBC 88/40 Measurement 
and 
Control Computer, 
the various terms of the equation 
will be reviewed. 


For Proportional control, the controller output is given 
by the equation: 


where m(t) is the output signal, b is an adjustable bias 
value, ko is a gain constant, and eft) is the measured er- 
ror signal. Proportional 
control systems are normally 


inter 


not used by themselves since corrections can not be 
made until an appreciable error has been detected-. In ad- 
dition, they tend to introduce oscillations into the system 
if the gain is set too large. Another disadvantage of pro- 
portional only systems is their inability to maintain a 
control element at some point (other than at its zero 
point using the bias term) in the absence of an error 
signal. 


The second term in the PID solution is the Integral. The 
result of this term is to eliminate steady-state error or 
offset. The elimination of the offset is an important con- 
trol objective; thus, the integral control term is widely 
used in conjunction with the proportional 
control ele- 


ment. The equation for the integral term is: 


The Derivative term in the algorithm is used to provide 
an output which is a function of the rate of change in the 
error signal. It anticipates the future behavior of the 
system and improves the dynamic response to the con- 
trolled variable by decreasing the process response time. 
The format for the derivative term is: 


where k2 is a constant representing the derivative time 
expressed in seconds or minutes. Because the output of 
the term is zero for a constant error, derivative control is 
never used alone in a control system. Instead, it is always 
used in conjunction with proportional and integral con- 
trol. The derivative term is seldom used in flow con- 
trollers 
because derivative 
control 
tends to amplify 
"noise" 
which is picked up in the flow measurement, 


leading to an unstable 
control 
system. In addition, 
systems which have very large time delays do not benefit 
from the use of this term. 


Implementation 
Using Digital Techniques 


With an exposure to the fundamental concepts of con- 
trol theory complete, the development of a solution us- 
ing the iSBC 88/40 Measurement and Control Com- 
puter can proceed. A modular "top-down" 
approach 


will be used in this application note. The general re- 
quirements will be defined and "black boxes" will be 
developed to meet these requirements. Finally, the in- 
dividual pieces will be combined to form a complete 
solution to the agitated tank control problem. 


An effective control algorithm must deal not only with 
the mathematical solution of the control equation, but 
must also provide tests on limits and error conditions. 


As this application 
note will show, the iSBC 88/40 


Measurement and Control Computer is easily able to 
support these additional requirements. 


Additional supporting functions are also needed to ef- 
fectively implement a complete control system solution. 
For example, provisions must be made to support input 
and update of the controller setpoints. Allowances must 
be made to modify control algorithm constants in order 
to "fine tune" the system after start-up. 
Raw analog 


data 
must be filtered 
to eliminate 
spurious 
sensor 


measurements 
and 
then 
must 
be converted 
into 


engineering units. In earlier system implementations not 
based on digital computers, 
these functions were per- 


formed using a "black box" approach. Here, each func- 
tion is considered separately and the final solution is 
composed of combinations of building blocks. 


Digital technology offers a simple analogy to this ap- 
proach. Because application design is performed with 
software, a "black box" design is available for use with 
microcomputers. 
The black box corresponds to a soft- 


ware "task" 
and the system is integrated into a func- 


tional unit using a real time operating 
system. The 


iRMX 88 Real Time Executive provides all· the tools 
needed by the software designer to implement his re- 
quired functions for the application. 
This application 


note will show how the iRMX 88 executive can be used 
to simplify the design and to provide significant features 
in a process design example. 


Figure 6 shows a block diagram of the operations needed 
to implement the control of one loop for the agitated 
heating tank. An attribute of using digital microcom- 
puters is that additional loops can be run using the same 
hardware 
and software 
until the I/O 
or processing 


capabilities have been exceeded. 


Each element of the block diagram represents one func- 
tion which must be performed by the system. A task will 
be written to perform the functions assigned to each 
block. When the tasks are configured together with the 
iRMX 88 executive, a complete control solution will 
result. Some key features of the iSBC 88/40 Measure- 
ment and Control Computer will now be examined and a 
typical implementation will be described. 


The information 
presented in Figure 6 indicates that 


many functions involve the manipulation of analog data 
and its conversion into a digital form usable by the pro- 
cessor. This involves the use of both hardware and soft- 
ware. This section of the application note demonstrates 
how the iSBC 88/40 board features can be applied to the 
solution of the analog portions of the system implemen- 
tation. Both software programming concepts and hard- 
ware support products are examined. 
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A digital computer performs most of the control system 
operations 
using software. Data is sampled from the 


process sensor and converted to an equivalent digital 
format. Subsequent operations use the digital form of 
the data. Unfortunately, 
this requirement for operating 


on sampled data, rather than continuous actual data, 
can lead to errors if the system is not properly im- 
plemented. Care must be taken to minimize errors when 
the original signal is digitized. Figure 7 shows how the 
digital signal may look when an analog signal is sampled 
using an analog to digital converter. A glance at the 
figure indicates that the error can be minimized by 
taking samples at shorter time intervals so that the stair- 
case more closely resembles the original signal. Indeed, 
this is true, but what sample rate is best for a particular 
input signal? 
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A rule for digital control system designers is that the 
sample must be performed more than twice each period 
of the original analog signal. Thus, the sampling period 
must be less than one half the period of the sinusoidal 


frequency component which must be digitized. Even this 
method does not, in itself, assure an accurate measure- 
ment. 
Figure 
8 shows the effects 
of the aliasing 


phenomenon on a high frequency signal. Aliasing con- 
verts the high frequency components into fictitious low 
frequency signals in the sampled results. Before data ob- 
tained from a digital system can be used, the unwanted 
signals must be filtered from the original sensor signal. 
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Two approaches can be considered for filtering the data. 
One is the creation of an analog low pass filter and the 
second is the implementation of a digital filter. Unfor- 
tunately, a digital filter cannot remove aliasing error and 
is normally used to provide filtering of very low frequen- 
cy oscillations. 
Analog 
filtering 
provides 
effective 


removal of unwanted frequencies but is expensive when 
attempting to gain sharp cut-off frequencies. A com- 
bination of the two technologies results in an ideal situa- 
tion when used with digital controllers such as the iSBC 
88/40 Measurement and Control Computer. 


inter 


The final choice of sampling rate is usually determined 
by examining 
the process 
to be controlled. 
If a 
mathematical 
first order transfer function can be ob- 
tained for the process, either theoretically or experimen- 
tally, then the choice should be to use one tenth of the 
process time constant. If no function can be obtained 
and the frequency of the input signal is known and 
bounded, a sample rate equal to at least twice the input 
frequency is used. If none of the above is known, a 
rough estimate for process applications is to use a I sec- 
ond sample period for flow measurements, a 5 second 
interval for level or pressure measurements, 
and a 20 


second 
interval 
for 
temperature 
or composition 
measurements. 
In any case, faster sampling than is 


necessary is a waste of computing power and limits the 
number of PID loops that can be supported by a given 
system. 


The elimination of high frequency noise in systems using 
Intel's control products is best accomplished using the 
iCS 910 Analog Termination Strip. This strip has provi- 
sion for the installation of a single pole RC low pass 
filter (details on the use of this strip in industrial control 
applications can be found in AP-52, Using Intel's Con- 


trol Series In Industrial Applications). 
In addition to 


providing a front-end low pass filter, the strip gives a 
simple method 
of terminating 
analog wiring to the 


analog to digital converter. Figure 10 indicates the cable 
connections which can be used to connect the analog in- 
put connectors of the iSBC 88/40 board to the iCS 910 
termination strip. This connection arrangement will pro- 
vide complete 
compatibility 
between 
the numbered 


channels on the termination strip and those defined by 
the measurement and control computer. 


The iSBC 88/40 board's 
application software can be 


used to eliminate the effects of low frequency noise in 
the sampled signal. This is done by implementing a sim- 
ple digital low pass filter. The equation for a first order 
filter is: 


where Sf represents the filtered output, a is a function of 
the cutoff frequency, Sm is the measured sample, and 
Sf' 
is the last filtered output result. If additional poles 


are required, the equations can be cascaded as required. 


inter 


The implementation of this filter using Intel's PL/M-86 
high level language is straightforward. 
A simple pro- 


cedure can be written in which the measured value, the 
last filter output value, and the value for a are passed 
with the call. The procedure returns the new filtered 
value. The code for such a procedure is shown in Figure 
11. Note that the computation is performed in steps to 
prevent any stack overflows from occurring when real 
numbers are used. This should be done whenever the 
algebraic equation exceeds eight terms. The 8087 stack 
used in internal operations 
can overflow when more 


than eight operations are nested together. Breaking the 
equation into smaller steps can prevent any overflow er- 
rors from occurring. 


Analog$filter$module: 
Do; 
Analog$filter: 
. 


Procedure (presenthalue, 
last$output, 
cutoff) real public; 


Declare (presenthalue, 
last$output, 
cutOff) pointer; 


4 
Declare New$signal 
based presenthalue 
real; 


5 
Declare Dld$filter 
based Iast$output 
real; 


6 
Declare Alpha based cutoff real; 


8 
Declare templ 
real; 


9 
Declare temp2 real; 


10 
Declare temp3 real; 


11 
Declare One real data (1.0); 


templ 
= Alpha" 
New$signal; 


temp2 = One - Alpha; 


temp3 =temp2 " Old$filter; 


New$filter=templ 
+temp3; 


Return New$filter; 


end Analog$filter; 


end Analog$filter$module; 


Before data can be sent to the filter, it must be converted 
into floating point format and then into engineering 
units. The conversion into engineering units can involve 
a complex algorithm if the raw data is non-linear. The 
design of future systems can be simplified if the pro- 
grammer generates procedures which are general enough 
to cover the majority of cases found in his application 
environment. 
The following example shows how the 
iSBC 88/40 board can be programmed to provide the 
linearization and conversion for the general case. 


LINEARIZATION 
FUNCTIONS 


The program developed for this application 
example 
uses an interpolation technique. A table look-up enables 
a program to be written which will support both linear 


and non-linear analog sensors. The number of entries in 
the table is a function of the desired resolution and of 
the non-linearity. For example, linear functions needing 
only scaling and offset (y =ax + b) require only two table 
entries. A separate table is maintained for each sensor 
channel. The program is written to support a maximum 
of 256 entries per channel which should provide at least 
0.1 percent accuracy for all but the most non-linear ap- 
plications. 


Each table entry consists of a raw value and a corre- 
sponding 
real engineering 
unit 
value 
expressed 
in 


floating 
point 
format. 
The linearization 
program's 


declaration of such a table is shown in Figure 12. The ap- 
plication software must determine the bracket or loca- 
tion of the terms in the table which lie above and below 
the raw input value. The algorithm to find the bracket in 
the table which corresponds to the raw data input can be 
programmed as shown in Figure I3. Once the bracket 
has been found, the actual engineering value can be 
calculated and passed back to the calling program. The 
code for performing the interpolation calculation might 
look like that shown in Figure 14. Data for the tables can 
be determined from known characteristics of the sensor 
or a program can be written which allows the user to 
enter known points into the table dynamically during 
calibration. 
In this application note, an assumption is 


made that the data has been entered into the table from 
known characteristics rather than actual calibration. 


Declare (table based table$pointer)(255) 
structure 
( 


x word, 


y real ); 


10 
Do while table (n).x < raw$value; 


11 
n=n+l; 


/" 
special case, above table "/ 


12 
If n > table$entries 


then do; 


14 
4 
eu=table(n-l).y; 


15 
4 
return eu; 


16 
4 
end; 


17 
3 
end; 


/" 
special case, below table "/ 


18 
If n=O 


then do; 


20 
eu = table(n).y; 


21 
return eu: 


22 
end; 


/* interpolateengineeringunits */ 
dx= f1oat(int(table(n).x-table(n -l).x)); 
dy= table(n).y-table(n -l).y; 
dr=f1oat(int(raw$Value-table(n -l).x)); 
eu=dr * dy; 
eu=eu / dx;' 
eu= eu+ table(n-l).y; 


One fmal component of the analog design which is re- 
quired is the creation of software which will actually in- 
terface with the analog to digital converter and transform 
data from the analog world into a digital domain. Again, 
a program should be developed which is general enough 
to handle a wide variety of applications. It should be com- 
patible with both the on-board AID sections and with the 
iSBC 311 Analog Input MULTIMODULE Board, which 
may be installed for analog expansion. 


The interface with the analog portions of the boards is 
easily handled using software. The ADC can be com- 
manded to select the desired analog channel and begin a 
conversion by sending the appropriate byte tontaining 
the channel and gain bits to a port corresponding to the 
ADC. When using the on-board converter, the iSBC 
88/40 board user should send the command byte to port 
OD8hex. The actual selection of the desired channel and 
the conversion takes only 50 microseconds, so little is 
gained by using an interrupt instead of status testing to 
detect the end of conversion. The status bit is tested by 
reading the input status port (OD8hex for the on-board 
converter). When the conversion is complete, the bit will 
have a value of O. 


Certain multiplexer components used in the ADC re- 
quire that 
a delay time be added 
to the basic 50 


microseconds for the channel to settle after a new gain 
setting has been selected before reading the sample and 
hold converter. The amount of delay is a function of the 
gain and varies from 0 (gain = I) to 30 milliseconds (gain 
=250). The analog driver software must take this settle 
time into account. Figure 15 shows the required settle 
times for the various gain settings. The delay is easily im- 
plemented using the facilities of the iRMX 88 nucleus. 
While the system is waiting for the settling time, other 
tasks can use the processor to execute their code. Figure 
16 provides an example of a program which gets data 
from the analog to digital converter for a selected chan- 
nel and gain. The iRMX 88 request for a time delay is 
implemented using the call to'RQWAIT 
specifying the 


desired delay. In the example, the system delay incre- 
ment is assumed to be 5 milliseconds, so the required 
number of delay increments is specified as 6 in order to 
wait for 30 milliseconds at high gains. Note that, for 


gains of one, the delay is skipped. After the required 
delay has elapsed, the converter is again activated using 
another output to its command port. This output must 
again include the channel and gain information. 


/* selectmux channel*/ 
14 
output(port$adr)=channel or gain; 


15 
if gain < 40h 
then do; 


/* settling delaylor high gains*/ 


17 
msg$ptr= rqwait(.timeout. 6); 


18 
output(portSadr)=channelor gain; 


19 
end; 
/* wa~ for end 01 conversion*/ 


20 
do while (input(port$adr)and 01h) > 0; end; 


/* get adc data */ 
22 
low$raw$data= input(port$adr)and OIOh; 


23 
high$raw$data= input(portSadr+ 1); 


24 
raw$data= shl(high$raw$data,8) or low$raw$data; 


A workable analog driver must provide more than just 
the ability to get data from a specified channel. At a 
minimum, the zero offset induced by the temperature of 
the circuitry must be removed from the raw data. In 
some cases, an additional correction is required to com- 
pensate 
for gain 
error 
induced 
by temperature. 


However, the effect of the latter is small and can usually 
be ignored. 


Provisions are included on the iSBC 88/40 Measurement 
and Control Computer to simplify the task of providing 
a zero offset correction. Wire-wrap stakes are mounted 


on the board to facilitate grounding one of the input 
channels. In the differential mode of operation, channel 
15 represents the zero reference offset voltage. If a data 
channel has the offset subtracted from it, the result will 
be a value which is compensated 
for offset drift and 


which is highly accurate over a wide range of board 
temperatures. 
Figure 17 shows the software which can 
be used to collect data from a channel and which will 
deliver a zero compensated value to a calling program. 
In Figure 17, note that the values are converted to an 
offset binary representation to be compatible with the 
standard output of the analog to digital circuitry. 


zero$data =get$channel (gain, ref$chan, port$adr); 


/' 
get data channel '/ 
' 


35 
raw$data =get$,channel (gain, channel, port$adr); 


/' 
support negative o"set '/ 
if zero$data > raw$data 
then do; 


raw$data =zero$data - raw$data; 
raw$data =8000h - raw$data; 


end; 
else do; 


raw$data =raw$data - zero$data; 
raw$data = raw$data + 8000h; 


end; 


38 
3 


39 
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40 
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The analog input driver required for the application can 
now be constructed using the software building blocks 
which have been created. Generally, the input data will 
consist of either thermocouple inputs or non-temperature 
sensitive inputs. The driver must be able.to support both 
by providing a selective cold junction compensation cor- 
rection for those channels which are designated as ther- 
mocouples. 


The problem is illustrated in Figure 18. The voltage 
which represents the temperature of the thermocouple 
consists of the sum of the actual thermocouple voltage 
plus the voltage which is generated by the thermocouple 
junctions created where the wiring is terminated. The er- 
ror introduced 
by the termination 
must be removed 


before a junction temperature can be calculated. If the 
thermo/voltage 
characteristics of the termination junc- 


tion are known, the induced error can be subtracted and 
the temperature of the thermocouple can be calculated. 


Two things must be known for the correction voltage to 
become available. First, the actual temperature 
of the 


junction board must be known. Second, the electrical 
characteristics of the junction with respect to tempera- 
ture must be defined. With this data available, the cor- 
rection voltage can be obtained using the linearization 
program which has been created as an analog building 
block. 


The first problem is solved by installing a temperature 
sensing circuit onto the iCS 910 Analog Termination 
Strip. Figure 19 shows such a circuit which can be used 
to provide an extremely accurate measurement of the 
board and terminator temperature. Note that the circuit 
is installed onto the termination board using the mount- 
ing locations originally designed for the installation of a 
low pass filter. The output of the temperature sensing is 


intel 


related only to the temperature 
of the sensor device 
which provides a current of I microamp 
per degree 
Kelvin through 
the 10K resistor. The temperature 
is 
related to the voltage by the equation: 


Thus, the voltage read from the termination strip as the 
temperature varies from 0 to 70 degrees Centigrade will 
vary from 2.73 volts at 0 degrees to 3.43 volts at 70 
degrees. The analog to digital converter should operate 
at a gain of one to read this voltage. This will provide a 
resolution 
(I bit change) of 0.70 volts / 0.00244141 
volts/bit or 286 bits170 degree change. This equates to 
about 0.25 degree per bit change. 


The second problem is solved by connecting a ther- 
mocouple, which is placed in an ice bath, to the iCS 910 
strip. The strip is placed into an environmental chamber 
and the output monitored as the board and junction 
temperature is varied. The output represents the correc- 
tion required at each temperature. Tests made for this 
application note indicated that the error was essentially 
linear over the board range from 0 to 70 degrees Cen- 
tigrade. The correction voltage was found to vary linear- 
ly from minus 0.102 millivolt at 0 degrees to 3.578 
millivolts at 70 degrees. This data was placed into a 
linearization 
table to give an offset correction 
for a 
measured temperature of the board. Figure 20 shows the 
table 
and 
the code 
required 
to correct 
the 
raw 
temperature value from thermocouple inputs. 


/* gel Ihermocouple relerence junction temp */ 
60 
j$raw = analog$to$digital$conversion ( 
gain$one, 
13. 
channel$data, porl$number ); 


tc = analog$linearization ( 


@cold$junction$table, 
2, 
j$raw); 


Ic = analog$lilter ( 
@Ic, 
@channel$data, lasl$lhermocouple, 
@channel$dala, tiller$culoft 
); 
raw = raw + unsign(tix(lc)); 
channel$data, lasl$thermocouple = tc; 


An analog input driver can now be constructed which is 
compatible with a variety of applications. It will run as a 
task under the iRMX 88 nucleus. In order to support up 
to "n" analog inputs, an exchange is used to store infor- 
mation about current active analog channels. User tasks 
requiring analog facilities send a request to the analog 


exchange indicating the parameters of the desired chan- 
nel. Because an exchange has a FIFO storage capacity 
for messages, each active channel is sampled by the task 
in turn, then placed back onto the exchange. A unique 
message is used to indicate the beginning of the channel 
requests. Figure 21 provides a partial listing of the code 
used to make up the analog input task. 


msg$ptr=rqwa~ 
(.analog$exch, 0); 
il channel$dala, type = nUII$type 
then last$channel = true; 
else do; 


/* test lor conversion time request */ 
It channel$data, converslon$counter = 0 
then do; 


/* get raw data trom adc */ 
raw = analog$to$digital$conversion ( 
gain. 
channel$number, 
port$number ); 
'* perform engineering unit conversion * / 
eu = analog$linearizatlon ( 
table$polnter, 
number$of$entrles, 
raw); 


/* tilter Ihe data */ 
eu= analog$tilter ( 


@eu, 
@channel$data, last$value, 
@fiIter$cutoft ); 
channel$data, lasl$value =eu; 


channel$data, conversion$tounter 
= conversion$interval; 


exch$ptr = channel$data, oufput$exchange$ptr; 
data$ptr = rqwait (exch$ptr, 0); 
data$message, value =eu; 
call rqsend (exch$ptr, data$ptr); 


/* decriment counter II not ready yel */ 
else channel$data, conversion$counter = 
channel$data, conversion$counter -1; 


end; 
call rqsend(.analgo$exch, 
msg$ptr); 


Updated data is stored in an output exchange in order to 
assure mutual exclusion of the engineering unit conver- 
sion of the data. Mutual exclusion guarantees that the 
data cannot be read by another task while it is being up- 
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dated (during the updating process, multiple bytes of 
data must be changed; until all are modified, the number 
cannot be considered valid). The exchange mechanism 
of iRMX executives supports the movement of messages 
(this might be compared to a letter in a mailbox). If the 
data is stored as a message in an exchange, it is available 
to the first user requesting it. While that user has the 
message (letter), it is not available to anyone else. When 
he is finished with it, he will return it to the exchange so 
that other users may operate upon the data. Note that 
the sample interval of each channel is selected by the re- 
questing task so that optimum processor efficiency can 
be obtained. 


Certain parameters used by the analog input task must 
be retained even if the system power is shut off for an 
extended period of time. These parameters are used to 
provide the task with unique information 
such as the 


channel and port address, the desired gain, the conver- 
sion interval and the linearization and engineering con- 
version data. On the other hand, some information used 
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by the task can be easily created dynamically and does 
not require the use of non-volatile storage. Examples of 
the latter category include addresses of the storage ex- 
changes and addresses of the various messages. 


The use of E2PROM on the iSBC 88/40 Measurement 
and Control Computer provides the mechanism for the 
storage of those parameters which must be occasionall'y 
modified. Figure 22 shows a possible technique for pass- 
ing the analog input task its required information 
and 


pointers to the non-volatile data. Intel's PL/M-86 pro- 
vides a convenient mechanism for referencing variables 
whose physical location is passed as a parameter. This is 
the BASED VARIABLE. A declaration is made which 
indicates the location of the variable containing the ad- 
dress of the data. For example: 


Declare CONSTANT$POINTER 
pointer; 


Declare CONSTANT based 


CONSTANT$POINTER 
real; 


pori number 


channel 
number 


gain 


thermocouple 
flag 


table poinler 
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number 
01 entrits 


lilter cuton 
I 
- 
_'0 
_11 


intel 


The CONST ANT$POINTER 
contains the address of 


the constant which is to be used in the calculations. Any 
program reference to CONSTANT will cause the pro- 
cessor to use the real number stored in the address 
pointed to by CONST ANT$POINTER. 


This technique allows a message to contain pointers to 
E2PROM constants which can be used by the task in 
performing 
its functions. 
Indeed, 
multiple levels of 
based variables can be used as shown in Figure 22. 


CONTROL 
ALGORITHM 


The implementation of a control algorithm on the iSBC 
88/40 computer involves more than just implementing 
the PID equation. To become truly cost effective, multi- 
ple loops must be supported by the board and error 
checking/correction 
must be included. 
As with the 


analog input functions, system control parameters must 
be maintained 
in non-volatile 
memory. 
Finally, 
the 


system must be capable of operating in real time with a 
minimum of required processor time. This section ex- 
amines some of the features which are used to provide 
these functions on the measurement and control com- 
puter. 


The first design goal is to support multiple control loops 
using as little of the processor's time as possible. The 
processing time is minimized by performing all complex 
mathematical 
computations 
using the 8087 math co- 


processor mounted on the iSBC 337 MULTIMODULE 
board. Certain details of the software implications of 
the co-processor are important to the system designer. 


In many cases, the iRMX 88 nucleus will provide all the 
required initialization operations 
for the co-processor 


chip. The nucleus sends a default control word setting 
the device to mask all exceptions and interrupts, define a 
64 bit precision, and to round up all operations. 
In an 


iRMX environment, the application programmer has no 
need to send additional 
mode commands to the pro- 


cessor. However, the mode can be changed by using the 
PLIM built-in procedure, 
SET$REAL$MODE, 
if re- 


quired. In the application code written for this applica- 
tion note, certain conversion algorithms required that 
results obtained from the math operations be truncated. 
To instruct the 8087 to perform this truncation, a com- 
mand word of OFBF hex is sent in the initialization seg- 
ment of a task. 


Multiple control loops are implemented using the iRMX 
88 exchange mechanism. Here, messages are queued at 
an exchange in a first in, first out (FIFO) manner. One 
message can be sent to the exchange for each control 
loop to be executed. A special message is placed into the 
exchange at control task initialization to be used as a 
pointer to the end of the queue. Each time the control 


task is to run, it will read messages sequentially from the 
exchange until it encounters its end of queue message. 
Each 
message 
corresponds 
to one control 
loop's 


specifications and is returned to the exchange when the 
loop has been completed. A separate control interface 
'task manages the control loop activation by sending a 
message containing the necessary parameters to the con- 
trol exchange. This technique allows the interface task to 
also remove a control task by taking the appropriate 
message from the exchange when parameter modifica- 
tions or control loop deletion is requested. 


Each message at the control exchange (in the application 
example, this exchange is called PID$EXCH) contains 
pointers to various other exchanges or data structures. 
The relationships of these structures is shown in Figure 
23. Note that some system parameters should be stored 
in non-volatile E2PROM memory. System constants are 
stored in an exchange pointed to by the primary control 
message. An exchange is used here so that the system can 
provide mutual exclusion of the data if it is required to 
modify one or more of the parameters while the control 
system is running. 
Additional 
exchanges are used to 


store the input and output terms in order to insure com- 
patibility with the analog input and output tasks. 


In order to function correctly, a digital implementation 
of a PID control algorithm 
requires operation 
at a 


known time interval. In the case of the implementation 
constructed for this application note, a time increment 
of 100 milliseconds was desired. The iRMX nucleus pro- 
vides the ability to perform a timed wait at an exchange 
via the call to the primitive procedure, RQWAIT. Un- 
fortunately, this procedure can not be directly used in 
the task to provide the required task delay. This is 
because the execution time of the task is a function of 
the number of loops being implemented and also varies 
slightly depending upon the program paths required by 
the data 
values. 
Thus, 
a mechanism 
must be im- 


plemented to provide the task synchronization. 


The desired time delay can easily be obtained by using an 
associated 
synchronization 
task. 
In this task, 
the 


RQWAIT primitive can be used with the required time 
delay. Because the task execution time is not a variable, 
this task can be used to provide synchronization for its 
supported task. Figure 24 shows how the two tasks can 
communicate with each other. Two exchanges are main- 
tained. One, called the PID bucket exchange in the im- 
plementation, is used by the main task to indicate that it 
is beginning its execution and that a new time period 
delay is to begin. The timer task (whose priority should 
be greater, i.e., having a smaller priority number) will 
wait at the bucket exchange for the message. When it is 
received, it will begin a delayed wait at an exchange. 
When the timeout period has elapsed, the message is sent 
to a second exchange (in the figure, this exchange is 


inter 


called the PID trigger exchange). The main task, after 
completing the servicing of all operational PID control 
loops, will wait at the trigger exchange for a message 
from the timer task. In the case of the application exam- 
ple, the message will arrive 100 milliseconds after the 
task began its last update of the control loops. 


When iRMX 88 timed wait operations are implemented 
on the iSBC 88/40 Measurement and Control Computer, 
timer 0 of the on-board 8253 programmable 
interval 
timer must be used. A wire wrap jumper must be installed 
to vector the output of the timer to one of the interrupts 
of the 8259A programmable 
interrupt controller chip. 
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Normally, 
interrupt 
level I is used for this timer; 
however, any available level may be selected and the 
iRMX nucleus can be configured to operate correctly by 
the Interactive Configuration Utility (ICU). A later sec- 
tion of this application note will explain the ICU interac- 
tion in more detail. The timed delay function will allow 
delay increments as small as one millisecond. Each call 
to the delayed wait function specifies the number of 
delay increments 
for which to wait (0 to 65535 in- 
crements may be specified in the call). Care should be 
taken when specifying a delay period of only one unit. 
The system is not always capable of resolving this delay 
accurately and an indeterminant 
delay of from 0 to 1 


unit may actually elapse. 


ANALOG 
OUTPUT 
FUNCTIONS 


Once the feedback loop of a control system has been 
sampled and a control signal generated by the PID con- 
trol algorithm, a final conversion must be made to pror 
vide an output compatible with the system control ele- 
ment. Because such a wide variety of control elements is 
available, the iSBC 88/40 board was designed to accept 
the output 
control circuitry as an expansion option 


rather 
than 
to build 
unnecessary 
components 
and 
drivers into the board. 


In most cases, the control element is driven with an 
analog signal, either a 4-20 milliamp current signal or a 
DC voltage. The iSBC 88/40 board is easily interfaced to 
the analog world using the iSBX 328 Analog- Output 
MULTIMODULE 
Board. The use of this board is so 


common with the measurement and control computer 
that it warrants the time to explain its operation in some 
detail. 


Each iSBX 328 board provides up to eight voltage or 
current outputs which can drive a wide variety of control 
devices. 


The use of intelligence on the MULTIMODULE expan- 
sion board is a key element providing the ability to incor- 
porate eight channels in a very small physical area. The 


capabilities of the intelligence allow the board to provide 
significant 
enhancements 
to the basic operational 


characteristics of the host iSBC 88/40 board. One exam- 
ple is the ability to perform diagnostics of the analog 
output module upon command from the 8088 processor 
on the host measurement and control board. 


The expanded capabilities b.ring with them a require- 
ment for some care on the part of the system designer. A 
fixed programming sequence and handshaking are re- 
quired 
to reliably communicate 
with the expansion 


board. An analog output driver is easily written which 
provides the necessary support for analog output signals 
associated with the control application. 


Each time a reset is issued to the iSBX 328 board, it ex- 
ecutes a test of its internal stored program to assure data 
integrity and of its usable RAM to insure that each loca- 
tion can be written to and read from correctly. If either 
of these tests fail, a bit in the status field will be set to in- 
dicate the failure. If the test is performed satisfactorily, 
the FO status register (bit 2 of the base port + 2) is set to 
indicate that the board is ready to receive an initializa- 
tion command. The initialization command is used to 
specify the operational mode and number of channels 
being used. 


The operational mode specifies which of four internal 
programs are to be used to move data between the iSBX 
interface and the outside world. Each program specifies 
a unique hardware configuration of the board. Two pro- 
grams are associated with unipolar 
operation 
of the 


DAC outputs. Program I is used when some channels 
are associated with voltage outputs and some are con- 
figured as current. outputs. Data directed to a current 
output will be internally scaled and offset before being 
sent to the DAC. Data specified as directed to a voltage 
output is not modified by the program. Program 2 in- 
dicates that either all eight channels are used for .voltage 
outputs or that all eight channels are used for current 
output. Current outputs will be offset by the hardware 
but no scaling is accomplished. This program 2 mode 
results in a 10070 increase in performance over what is 
specified in the data sheet of the iSBX 328 board. 


Both unipolar programs assume that the data is pure 
binary formatted with a 0 hex corresponding to a voltage 
level of 0 volts (or 4 milliamps). A value of OFFFO hex 
will generate a voltage of 4.99 volts (in the current con- 
figuration mode, program 1 will result in a 20 milliamp 
current while program 2 will result in an output of 24 
milliamps). 


There are also two operational modes which can be used 
to support a bipolar operation. 
Program 2 provides a 


direct hardware support capability for those cases where 


all outputs are either configured as entirely voltage or 
entirely current outputs. No adjustments are made to the 
data prior to being sent to the DAC. The data format 
used for both 
bipolar 
modes 
is the offset 
binary 


representation 
of a number. 
Negative numbers 
are 


represented by the values 0 ( - 32752) to 8000 hex (0). 
Positive numbers range from 8000 hex (0) to OFFFOhex 
(+ 32752). Channels defined as current outputs have no 
legal negative output values. 


Finally, program 4 is used to support bipolar operations 
where the outputs 
are mixed between current 
and 


voltage. The program does not alter data destined to 
voltage channels but does offset and scale data for chan- 
nels designated as current outputs. 


Once the device has been initialized, subsequent data 
transfers are all through the data transfer port located at 
the base address 
of the board's 
MUL TIMODULE 


socket. Before each write to the device, the driver soft- 
ware must check the IBF bit (bit 1)of the status to verify 
that the input buffer is not full. An additional bit is used 
to specify to the host processor which data byte (high or 
low) is next to be passed. The low order bits of the low 
data byte specify which channel the data is for and also 
what configuration (voltage or current) corresponds to 
that channel. 


Like the analog input task, the application driver for the 
analog output can be an iRMX 88 task using exchanges 
and messages for data transfer. 
In the example im- 


plemented 
for this application 
note, 
an exchange, 
DAC$EXCH, was dedicated to the control of the task. 
It contains 
messages .which specify the output 
port, 
channel used, and output mode (current or voltage). The 
task runs at a twenty millisecond time interval and up- 


. dates each channei as indicated by the control messages. 


The location of the exchange used to store the output 
data is also specified by the control message. The use of 


this exchange mechanism provides mutual exclusion of 
the output data. 


The external connections to the iSBX 328 analog output 
board can be made using the Intel iCS 910 Analog Ter- 
mination Strip. When used in this mode, the analog out- 
puts are available 
on the terminal 
strips originally 


designated as analog input channels. Figure 25 shows 
how the interconnect cable can be used to install the ter- 
mination panel to the board. 


Several references have been made to the advantages 
gained by using E2PROM 2816 devices on the iSBC 
88/40 board for the storage of non-volatile variables. 
Many configurations 
mixing E2PROM 
devices with 


combinations 
of EPROM, 
ROM, 
and/or 
byte wide 


RAM are possible. Support is provided for the installa- 
tion of one, two, four, or eight (using the iSBC 341 
MULTIMODULE EPROM board) 2816 devices. Com- 
plete E2PROM 
write capability 
is provided 
on the 


board. The Intel supplied hardware for this support in- 
cludes a switching power supply and wave-shaping cir- 
cuitry. Only minimal user programming overhead is re- 
quired by the application program. 


The on-board wave-shaping circuitry provides a 2816 
compatible 
programming 
pulse of approximately 
16 


milliseconds duration. 
In order to generate this pulse, 


use is made of the on-board 8253 programmable interval 
timer. Wirewrap jumper posts are provided to route the 
timer output to the pulse generator. The gate to the timer 
is connected using an additional jumper to the memory 
decode logic to signal a write request to a 2816 device. 
User software must be provided to program the 8253 for 
the generation of a 14 millisecond pulse. This code is 
most easily located in the initialization portion of one of 
the application tasks associated with writing data into 
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the devices. Only three lines of PL/M-86 code are re- 
quired to perform the initialization. The application ex- 
ample includes the code: 


output(OD6H) =OB2H; 


I· timer 2 to mode 2 ·1 
output(OD4H) =OOOH; 


I· most significant byte ·1 
output(OD4H) =038H; 


I· least significant byte ·1 


The hardware will now generate the appropriate 
pro- 


gramming pulses to write into the 2816 each time data is 
written into an address occupied by the device. When the 
EPROM size is larger than 2K bytes size of the 2816, the 
system will create a duplicate image of the 2K block as 
many times as is required to fill the size specified for the 
EPROM. 
For example, if 2732A EPROM devices are 


used and one 2816 is installed at a base location of 
OF8000hex, one image of the E2PROM data will occupy 
the memory from OF8000hex to OF87FF hex while a sec- 
ond image will be seen from OF8800hex to OF8FFF hex. 
Reads or writes to either image will access the same data 
and either may be used. 


The user must consider the possibility of system power 
failures and their impact when designing systems which 
use the iSBC 88/40 board's E2PROM capabilities. This 
is especially true in systems whose power supply for the 
+ 5 volt source is protected by a crowbar circuit. The on- 
board switching power supply which generates the high 
voltage programming pulse operates at very low input 
voltages and its RC time constant will provide signifi- 
cant voltage levels even if the + 5 volt input supply is 
abruptly 
removed. 
The presence of a programming 


voltage in the absence of a + 5 volt supply to a 2816 can 
cause irreversible damage to the E2PROM chip. The 
potential for this condition during a write cycle must be 
considered by the designer. Figure 26 shows a circuit 
which can be added to the system and connected via the 
iSBC 88/40 board's P2 connector if desired. The pur- 
pose of the circuit is to crowbar the Vpp programming 
voltage to the + 5 volt supply if the + 5 volt voltage level 
drops 
below about 
4.5 volts, 
thus preventing 
any 
damage to the 2816. 


From a software standpoint, 
only two items need be 


given attention during the writing of E2PROM devices 
on the board. First, before any location can be written in 
the 2816, the location must first be cleared to an initial 
value of OFF hex. Unless this value is already present in 
the device, two write cycles are required to store new 
data (the 2816 has a chip erase mode but it is not sup- 
ported on the iSBC 88/40 board). The second item in- 
volves inhibiting interrupts during the write cycle. The 
programming 
pulse generation 
circuitry uses the on- 


board timeout circuitry, 
so the timeout interrupt, 
if 


used, must be masked off prior to beginning the write 
cycle (this implies that the hardware 
for the timeout 


acknowledge must be installed to all the circuitry to 
become a part of the pulse generator). In an iRMX 88 
environment using timed waits, the interval timer must 
also be masked off during the write cycle. If these inter- 
rupts are not masked off, the processor can respond to 
an interrupt and begin modifying its internal registers 
which point to the memory. This will result in incorrect 
programming of the E2PROM device. An example of 
the code which might be used to program a 2816 is 
shown in Figure 27. The programmer 
should keep in 


mind that, during the programming 
of the 2816, the 


iAPX 88/10 processor is in a wait state and cannot pro- 
cess any instructions. Thus, for each byte written, ap- 
proximately 36 milliseconds must elapse before process- 
ing can again begin (18 milliseconds for the clearing of 
the byte and another 
18 for the data write). If timed 


waits are being performed, an error will be introduced 
into the system. Some critical applications may need to 
take this into account. 


Q1 
2N3904 


VR1 
1N5228 
3.9v 


then do; 


366 
disable; 


367 
call movb(@erase$pattern(O), 


@constants(k).lable$poinler, 
4): 


368 
conslanls(k).table$pointer= 


@conslanls(k).linearization$table(O); 


369 
enable; 


370 
end; 


System Implementation 


The application programs for the example described in 
this application note have been implemented using Ver- 


sion 
1.1 of the iRMX 
88 executive. 
The use of the In- 


teractive 
Configuration 
Utility 
(ICU88) 
considerably 


reduces 
the effort 
required 
to bring a system 
on line by 


providing 
a question 
and answer 
session 
with the pro- 


grammer. 
The output 
of the ICU 
consists 
of a system 


configuration 
module 
and a submit 
file which provides 


most of the required 
LINK 
and LOCATE 
commands. 


In the application, 
a system 
time wait 
increment 
of 5 


milliseconds 
was chosen. 
Figure 
28 shows 
the dialogue 


required 
to implement 
the timed 
wait feature 
using the 


board 
with the output 
of channel 
0 (from 
the 8253 pro- 


grammable 
interval 
timer) connected 
to interrupt 
level 2. 
Note that the system time unit of 6140 corresponds 
to a 5 


millisecond 
increment. 


INTERRUPTS: Y 


8259A PORT: COH 


8259 INTERVAL: 
2 


INTERRUPT SERVICE ROUTINE VECTOR 8ASE: 56 


TIMEO WAITS: 
YES 


TIMER LEVEL: 2 


8253 PORT: OOH 


SYSTEM TIME UNIT: 6140 


Additional 
entries 
into the ICU define 
the system 
tasks 


and their associated 
exchanges. 
The desired 
locations 
of 


the RAM and EPROM 
are specified 
and the configura- 


tion 
modules 
created. 
The 
location 
of 
the 
E2PROM 


module 
is specified 
in one of the user created 
modules 
as 


a public pointer 
which is initialized 
with the base address 
of the device. 
An example 
might 
be: 


e2prom$module: 
do; 
declare 
e2prom$pointer 
pointer 
public 


data 
(Of8000h); 


end e2prom$module; 


All references 
to the data 
structures 
in the 2816 are by 


means 
of a based 
variable 
or structure. 


Before 
executing 
the 
submit 
file 
for 
a 
ROM 
based 


system, 
it is necessary 
to edit the LOCATE 
command 
to 


include 
the BOOTSTRAP 
request. 
This will assure 
that 


the locator 
places a long jump at the reset vector location 
when the system 
is executed 
out of EPROM. 
Execution 


of 
the 
LOCATE 
facility 
will generate 
a warning 
38 


which should 
be ignored. 
The corrected 
LOCATE 
code 


is shown 
in Figure 
29. 


ISIS· II MCS-86 
LOCATER. V1.3 INVOKEO 8Y: 


LOC86 :F1:AOCINP.LNK 
TO :F1:AOCINP 
MAP 
PRINTI :F1 :AOCINP.MP2)& 
BOOTSTRAP OROER(CLASSES(OATA, STACK, COOE))& 
AOORESSESI CLASSES(COOE(OFCOOOH), OATA(000400H))) 
WARNING 38: SEGMENT WITH MEMORY ATTRIBUTE NOT PLACEO 


HIGHEST IN MEMORY SEGMENT: 
MEMORY 


The total control 
system for the application 
example 
can 


now 
be 
assembled 
using 
the 
hardware 
and 
software 


discussed 
in this note. 
The same "black 
box" 
approach 


used 
in hardware 
designs 
can 
be extended 
to indude 


both software 
and hardware 
implementations. 
Figure 30 
shows the complete 
solution 
to the control 
of up to eight 


agitated 
heating 
tanks. 
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The purpose of this application note is to illustrate how 
the Intel iSBC 88/40 Measurement and Control Com- 
puter can be used to solve a complex control application. 
This has been done in Intel's lab and the results obtained 
from operating the board indicate that the system per- 
formance is sufficient to support the operation of eight 
loops each 100 milliseconds. Observed operation of the 
analog input and engineering unit conversion task in- 
dicated a 4 millisecond per channel execution time. The 
actual PID code required only 5 milliseconds per loop to 
execute. 


The ease of implementation and fast execution time for 
multiple complex loops is a result of many Intel product 
features. For example, the use of the iRMX 88 Real 
Time Executive provided fast, small, and easy-to-use 
multitasking real time software for use on the single 
board computer. The iSBC 337 MULTIMODULE Nu- 
meric Data Processor Board enabled the use of high ac- 


curacy, easy-to-use floating point calculations without 
taking excessive execution time. If desired, a fixed point 
integer math algorithm could have been substituted for 
the floating point without changing the system per- 
formance appreciably. 
The iSBX 328 Analog Output 


MULTIMODULE Board provided low cost customiza- 
tion of the base board to support a variety of controllers 
and actuators. 


Finally, the use of the Intel 2816 E2PROM provided the 
non-volatile storage for system setpoints and constants 
which is required in a control situation. 


Above all, the iSBC 88/40 Measurement and Control 
C9mputer provided a platform and execution vehicle for 
mounting 
and 
operation 
of the various 
ancillary 


features. 
Its iAPX 
88/10 
processor, 
memory 
and 


MULTIMODULE expansion sockets provided the flex- 
ibility to easily customize the board to a particular ap- 
plication environment. 


The programs which were used to construct the applica- 
tion example are available from Intel through Insite. 
Insite, 
Intel's 
Software 
Index and Technology 
Ex- 


change, is a collection of programs, subroutines, 
pro- 


cedures and macros written by users of Intel's 8008, 
8080, 8085, 8086, 8088, and 8048 microcomputers. 
In- 


formation on how to join Insite and obtain the source 
code can be obtained from your local Intel sales office or 
distributor, 
or by writing to: 


Europe 


Intel International Corp. S.A. 
User's Library 
Rue du Moulin a Papier 51 
Boite I 
B-1160 Brussels, Belgium 


Intel Corporation 
User's Library 6-5000 
Microcomputer Systems 
3065 Bowers Avenue 
Santa Clara, California 95051 


Intel Japan K.K. 
User's Library 
Flowerhill-Shinmachi, East Bldg. 
1-23-9 Shinmachi, Setagaya-ku 
Tokyo 154, Japan 
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Reduce your ,uC-based system design time 
by using single-board microcomputers. 
Assembled boards 
in the SBC-80 series offer stock answers to custom demands. 


System 
designers 
eager to take advantage 
of the 


dramatically 
increased 
capabilities 
of 
micro- 


computers 
have been hindered two ways: Their pro- 


duction volumes have been too low to amortize soft- 
ware and hardware 
development 
costs effectively, or 
hardware 
subtleties 
and test requirements 
have con- 


fined them to fully assembled 
and tested computer 


subsystems. 
But now those obstacles 
are overcome 
with families 
of fully assembled 
and tested 
micro- 


computers and system-expansion 
boards like the Intel 


SBC-80 series. 
They are ready-to-use, 
flexible and 


inexpensive-prices 
range from just $195 to $825 in 


unit quantities. 


The main members 
of the SBC-80 family are the 


80/04, 
80/05, 
80!lOA, 
80/20 
and 
80/20-4 
central- 


processor boards, with either an 8080A or 8085 micro- 
processor acting as the master 
CPU (Table 1). Most 


of the boards measure 
6.75 x 12 in. and contain the 
CPU, clock, read/write 
memory, 
control ROM, I/O 


ports, serial communications 
interface 
and bus-con- 


trol logic. 


I/O interfacing 
is an area where design flexibility 
is essential to meet changing requirements 
efficiently. 


The programmable 
parallel and serial I/O structures 
of the boards make them versatile enough to do just 
that. What's more, upgrading 
system performance 
is 
easy thanks to the SBC-80 system bus, the Multibus, 
which permits 
modular 
performance 
expansion. 


The Multibus provides a defined, standard 
interface 


between the SBC-80 single-board 
computers 
and ex- 


pansion boards. As many as 16 SBC-80 family boards 
can simultaneously 
share the bus. 


All in the SBe-80 
family 


As 
exemplified 
by 
the 
block 
diagram 
of 
the 


SBC-80/lOA (Fig. I), the SBC-80 microcomputer 
sys- 


tem has all that's 
needed for many applications. 
The 


SBC-80/10A is the oldest board in the family and has 
been widely imitated 
since it was one of the first 


"standardized" 
microcomputers 
commercially 
avail- 


able. 


The CPU section of the 80!lOA board consists of 
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the 8080A CPU, the 8224 clock generator 
and the 8238 


system controller. 
Capable of fetching and executing 


any of the 8080A's 78 instructions, 
the CPU section 


can respond to interrupt 
requests 
originating 
on and 


off the board. (For more about the 8080A, see "Micro- 
processor 
Basics, Part 2," ED No. 10, May 10, 1976, 


p. 84). 


The system-bus 
interface section includes an assort- 


ment of circuits 
to gate the interrupt 
and hold re- 


quests, the ready signals, and a system-reset 
signal. 


Other 
circuits 
drive the various 
control 
lines. Two 


8216s help drive the bidirectional 
data bus, and six 
8226s drive 
the external 
system-data 
and address 


buses as part of the SBC-80/10A's Multibus interface. 


The RAM section of the 80/lOA consists 
of 1024 


bytes of static 
MOS memory. 
For program 
storage, 


up to 8192 bytes of ROM can be mounted on the board 
in 1024-byte increments 
by means of a 2708 or 8708 


EPROM, an 8308 mask-programmed 
ROM, or in 2048 


bvte increments 
via the 2716 EPROM or 2316 ROM. 


. A serial interface 
on the board uses an 8251 pro- 


grammable 
universal 
synchronous/asynchronous 


receiver/transmitter 
to provide a serial-data 
channel. 


The serial port operates at programmable 
rates up to 


38,400 baud (synchronously) 
or 19,200baud (asynchro- 


nously) with a choice of character 
length, number of 


stop 
bits, 
and 
even, 
odd or no parity. 
On-board 


interfaces provide direct EIA RS-232 or teletypewriter 
current-loop 
compatibility. 


Two 
8255 
programmable 
peripheral 
interface 


circuits provide 48 I/O lines for transferring 
data to 


or from peripheral 
devices. Eight already-committed 


lines 
have 
bidirectional 
drivers 
and 
termination 


networks 
permanently 
installed, 
so that they can be 


inputs, 
outputs 
or bidirectional 
(jumper-selectable): 


The other 40 lines are uncommitted. 
On-board sockets 


permit 
drivers 
and termination 
networks 
to be in- 


stalled, as needed. Since software configures the I/O 
lines, I/O can be customized 
for every application. 


The 80/10A also responds to a single-level interrupt 


that 
can originate 
from one of many 
sources, 
the 


USART, programmable 
I/O and two user-designated 


interrupt-request 
lines. When an interrupt 
is recog- 


nized, a Restart-7 
instruction 
is generated, 
and the 


processor 
accesses 
location 
38H to get the starting 


address 
of the service routine. 


System expansion and support 
are possible with a 


wide variety 
of alternate-source 
CPU, memory, and 


I/O boards (Tables 2 and 3). Up to 65,536 bytes of ROM, 
PROM or RAM can 
be accessed 
by one 80/l0A. 
Expandable 
backplanes and card cages are also avail- 


able to support 
multiboard 
systems. 


Interfacing 
starts with the bus 


Although 
the 
SBe-80/10A 
is a complete 
micro- 


computer 
system, it can be expanded readily or it can 


serve as a primary 
master controller for other micro- 


computer cards. The 80/lOA has five edge connectors, 
three on the top of the board and two on the backplane, 
or bottom, side. Two of the "top" connectors, J, and 
J" serve as parallel I/O ports, while Ja is a serial I/O 
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port. All parallel 
I/O lines on the 50-contact J, and 
J2 connector 
areas 
are paired 
with an independent 
signal/ground 
pin to permit alternate 
signal/ground 


wiring when using flat-cable interconnects. 
Serial port 


Ja uses a 26-contact 
PC-edge connector 
to provide 


interfaces 
for both RS-232 and current-loop 
devices. 


To communicate 
with 
other 
system-compatible 


boards, the 80/10A uses the 86-pin Multibus (P,). To 
provide accessible test points, the 80/lOA has a 60- 
pin edge connector 
(P2). 
The control signals on the 


Multibus 
provide 
the real power and capability 
in 


control applications. 


Of the 86 pins that make up the Multibus, 
24 are 


assigned to power and ground, 16 to addressing, 
eight 


to bidirectional 
data, 
and 12 to signal and control 


, 


INTERRUPT 
REQUEST 
LINE 


USER 
DESIGNATED 
PERIPHERALS 
D 
1)-48 PROGRAMMABLE 
PARALLEL 
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21NTERRUPT 
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1. Based on an 8080A I'P, the SO/lOA microcomputer 
has 


a 
straightforward 
design 
suitable 
for 
general-purpose 


computing 
and control. 
The board has 48 programmable 


1/0 lines and 
serial 
interfaces. 


COMMON 
HIGH 
SPEED 
MATH 


PftOCESSOR 


(SBC 3101 


2. 
The Multibus 
interface 
for the SBC-80 
CPU boards not 


only 
permits 
simultaneous 
multiprocessing, 
but 
also 


enables 
several 
processors 
to 
share 
the 
same 
bus 
and 


(these 12 are defined in Table 4). The remaining 
26 


pins are unassigned 
at this point. Higher capability 


SBC-80 products, 
though, are in development. 
These 


boards will use many of the unassigned 
lines (eight 
unassigned 
pins are allocated for additional 
bidirec- 


tional data lines). The remaining 
lines provide multi- 
level (eight) interrupt 
lines, various control lines and 


a multi master, bus-arbitration 
control structure 
(Fig. 
2). Address 
and data 
lines are three-state, 
and the 


interrupf 
and control 
lines are open-collector. 
Boards 
using 
the 
Multibus 
have a master-slave 


relationship: 
A bus master-such 
as an SBC 80 CPU 


board, a DMA controller or a diskette controller-can 
control the command 
and address 
lines. Conversely, 


slave boards-such 
as a memory, 
I/O-expansion 
or 
mathematics 
boards-cannot 
control the bus. 


Arbitration 
resolves priority 
disputes 


In multimaster 
systems, 
the bus-arbitration 
logic 
uses the CCLK signal of the bus to provide a timing 
reference to help satisfy many simultaneous 
requests 


for bus control. As a result, different 
speed masters 


peripheral 
devices. 
Arbitration 
logic 
on the 
CPU boards 


decides 
which 
board 
gets on the bus first 
if several 
units 


simultaneously 
access 
the 
bus. 


can share resources 
on one bus. Actual transfers 
on 


the bus proceed asynchronously 
with respect to the 


bus 
clock. Once bus 
access 
is granted, 
single 
or 


multiple read/write 
transfers 
can proceed at up to 150 


kbytes/s 
for CPU operations 
and up to 1 Mbyte/s for 


DMA operations. 
The bus 
has 
a bandwidth 
of 5 


Mbytes/s 
so that future 
performance 
enhancements 


may be directly 
supported. 


Both serial and parallel modes of bus-priority 
reso- 


lution are available. 
In the ,serial mode, up to three 


masters 
can share 
the system 
bus, with 
requests 


ordered on the basis of bus location. Each master on 
the bus notifies the next one down in priority 
when 


it needs to use the bus, and monitors the bus-request 
status 
of the closest higher-priority 
master. 
With an 


external priority network, up to 16 masters can share 
the bus. 


The dual-bus nature 
of the Multibus permits 
each 


processor-based 
master 
within 
the system 
to retain 


its own local memory and I/O, which it uses for most 
operations. 
Such local operations occur entirely on the 


individual 
board and don't require 
the system 
bus. 


In contrast to the dual bus architecture, 
all masters 


SSC 80104 
SSC 80105 
SSC 80/10A 
SSC 80/20 
SSC 80/20-4 


CPU 
8085 
8085 
8080A 
8080A 
8080A 


EPROM capacity 
(bytes) 


(with 
2716) 
4096 
4096 
8192 
8192 
8192 


(with 
2708) 
2048 
2048 
4096 
4096 
4096 


RAM 
(bytes) 
256 
512 
1024 
2048 
4096 


Programmable 
parallel 
1/0 
lines 
22 
22 
48 
48 
48 


Serial 
1/0 capability 
RS232C 
RS232C 
RS232CfTTY 
RS232C2 
RS232C2 


SID/SOD'. 
2 
SID/SOD!. 
2 
USART 
USART 
USART 


Timers 
1 
1 
0 
2 
2 


Interrupt 
levels 
4 
4 
1 
8 
8 


Multibus 
interface 
None 
Multi-master 
Single-master 
Multi-master 
Multi-master 


Price 
(unit 
quantity) 
$195 
$350 
$495 
$735 
$825 
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sac 
016 
sac 
032 
sac 
048 
sac 
064 
sac 
094" 


sac 
416 


sac 
508" 


Combma- 
sac 
104 


ticn 
memory 
and I/O 


16 kbyte dynamic RAM 
32 kbyte dynamic RAM 
48 kbyte dynamic RAM 
64 kbyte dynamic RAM 
4 kbyte CMOSstatic 
RAMwith 96 hour bat- 
terv backun. 
1'6 kbytes us~!,g2708 
tvne' 1024 x 8, EPROM 
32 input lines/32 out- 
put 
lines, 
all 
buf- 


fered/terminated 


48 programmable par- 
$ 400 


allel 
lines 
with 
full 


bufferi ng/term ination 
options, 
full 
RS232C 


porI, 
1 ms real-time 


clock, and 8-line inter- 
rupt control 


~~e'irol~~:~m~~~e~~~i 
$ 395 


bufferi ng/termination 
options, 
real-time 


clock 
(interval 
is 


jumper 
selectable to 


0.5, 1, 2, or 4 ms), and 
8-level programmable 
interrupt control. 
Four 
programmable 
$ 650 


sy nc hro n0 us/a syn- 
chronous serial ports, 
each with: 
program- 
mable baud rates, pro- 
grammable 
data for- 


mats, 
programmable 


interrupt 
control. 
16 


RS232C buffered pro- 
grammable 
parallel 


I/O lines configured as 
a aell Model 801 auto- 
matic calling unit in- 
terface. Two program- 
mable 
16-bit interval 


timers (usable as real- 
time clocks), and soll- 
ware selectable loop- 
back of serial ports for 
diagnostic use. 


48 
optically 
isolated 
$ 395 
lines; 24 input 16 out- 
pul, and 8 program- 
mable (in/out), 8-level 
programmable 
inter- 
rupt control, and 1 ms 
real-time clock. 
16/8 
(single-ended/ 
$ 895 


differential) 
12-bit aid 


channels: user expan- 
dable 
on-board 
to 


32/16 channels 


Four 12-bit d/a chan- 
$ 750 


nels 


Combination 
analog 
$1125 


I/O; same aid capabili- 
ty as sac 
711 plus 2 


d/a channels 
8 
kbytes 
capacity 
$ 715 


(sockets) using 2716 
(2 k x 8) EPROMor 4 
k using 2708. 4 kbytes 
dynamic RAM,48 pro- 
grammable 
parallel 


I/O lines, with full buf- 
fering/termination, 
as 


options. RS-232Cport, 
alms 
real-time clock, 
and an eight-line inter- 
rupt control 


ReqUIres + 5 V only 
h"T.'"'' 
DI""~}, 
Fehruary 
I. 197R 


Price 
(unit 
qty) 
$ 8z5 
$1360 
$1860 
$2200 
$ 795 


$ 295 


$ 350 


in multimaster/single-bus 
systems 
use the common 
bus for all instruction 
or data fetches or whenever 
data must be written 
to output 
devices or memory. 
Rapidly, then, the system bus becomes the bottleneck 
for over-all system 
throughput. 
Masters 
in SBC-80 


systems only use the Multibus when data or instruc- 
tions are resident 
in common, or global, memory or 


I/O. Since masters can request the Multibus simulta- 
neously, on-board arbritration 
logic resolves any mul- 
tiple contention. 


Examine 
board 
performance 


A look at 
the 
entire 
family 
of SBC-80 micro- 


computers 
reveals varied levels of performance. 
All 


five boards are inexpensive, but the most inexpensive 
is the 80/04, which costs $99 in lOO-unit quantities, 
and is intended 
for stand-alone 
applications. 
To get 


the cost down, the board was designed to use the 8085 
CPU and the 8155 RAM, timer and I/O circuit. 


The 80/04 contains an 8085 CPU, 256 bytes of RAM, 
space for up to 4 kbytes of EPROM (two 2716 EPROMs, 
or two 2708 EPROMs), 22 programmable 
parallel I/O 


lines with sockets for buffer and termination 
options, 


a 14-bit programmable 
timer/event 
counter, and pro- 
vision for an RS-232-C serial 
port 
using 
the 8085 


SID/SOD 
serial interface. 
The board can also house 


an on-board +5- V regulator, so an unregulated 
voltage 
can be connected. 


The next step up, the 80/05, has the same architec- 


ture and connector 
types and pinouts 
as the 80/04. 


Direct 
software 
compatibility 
is achieved 
with the 
same CPU along with the same RAM, ROM, I/O, and 
timer addressing. 
However, the 80/05 contains twice 


as much RAM as the 80/04. And since the 80/05 has 
the full Multibus multimaster 
interface, 
80/05-based 
systems 
can be expanded 
with any of the Multibus- 
compatible 
boards 
from Intel or other suppliers. 


The SBC-80/lOA comes next. It provides more on- 


board 
memory 
and 
I/O 
for systems 
requiring 
ex- 
panded on-board resources. Based on the 8080A CPU, 
the board contains 
1 kbyte of RAM, up to 8 kbytes 
of EPROM/ROM, 48 programmable 
parallel I/O lines, 
a full USART serial 
port with 
RS-232-C and tele- 


Same as sac 104. ex- 
$ 815 
cept has 8 kbytes of 
dynamic RAM 


Same as sac 104. ex- 
$ 985 
cept has 16 kbytes of 
dynamic RAM 
High speed mathema- 
$ 595 
tics processor mclud- 
ing floating-point 
ca- 


pability (32 bit). 
Dualsingle-densitydis- 
$ 995 


kelle controller 


Quad 
double-density 
$1290 


diskette controller 
DMA controller, 
up to 
$ 450 


1 MHz transfer rates 


typewriter 
interfaces, 
and a full Multibus 
interface 


(but only sin~le-master 
capability; 
the board has no 
multimaster 
capability). Intended for single'CPU sys- 
tems with only one other 
Multibus 
peripheral 
con- 
troller, 
the 80/lOA can interface 
with such as the 
SBC-20! or SBC-202 single and double-density 
dis- 
kette controllers, 
or the SBC-50! DMA controller. 
System designers requiring 
the same on-board I/O 
capability 
as the SBC-80/lOA but with more RAM, 
more efficient 
real-time 
capability, 
and full multi- 
master Multibus control can go further 
up the ladder 
to the SBC-80/20 or SBC-80/20-4. These boards differ 
only in that the 80/20 contains 2 kbytes of RAM and 
the 80/20-4 contains 
4 kbytes. Both boards can hold 
up to 8192 
bytes 
of ROM or EPROM, handle 
up 


§ 
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3. Programmable 
I/O lines 
from 
the 
SBC·aO 
parallel 
interfaces 
can be set so that they are individuallyprogram- 
mable as inputs or outputs (a). byte-programmable as 
inputs or outputs with handshaking (b). or bidirectional 
on a byte-programmable 
basis (c). 


to eight levels of prioritized 
interrupt, 
and share the 


Multibus in the multimaster 
mode. Either board has 


two programmable 
interval 
timers/event 
counters. 


Auxiliary 
power buses and memory-protect 
control 


logic on the board permit battery backup of the RAM. 


Take advantage of interrupts 
and timers 


Real-time applications frequently 
require that high- 


priority 
programs 
operate 
on the basis of external 


events, time-of-day, 
or elapsed time without 
impact- 


ing current 
background 
processing. 
These 
multi- 


programming 
requirements 
are 
supported 
in the 


80/20 and 80/20-4 by an eight-level 
programmable 


interrupt 
controller 
(PIC) and 
two programmable 


interval 
timer/event 
counters. 
The priority 
level of 


any event generating 
an interrupt 
request is assigned 


through jumper 
selection and the priority 
algorithm 


chosen by system 
software. 


Any combination of interrupt 
levels may be masked 


by storing a single byte in the interrupt-mask 
register 


contained by the PIC, whose four software-selectable 
priority algorithms 
are described in Table 5. The PIC 


generates a unique memory address for each interrupt 
level. These addresses are equally spaced at intervals 
of 4 or 8 bytes (software-selectable). 
The resulting 32 


or 64-byte 
block may 
begin at any 32 or 64-byte 


boundary 
in the 65,536-byte memory space. A single 


8080A jump 
instruction 
at each of these addresses 


then provides linkage to locate each interrupt 
service 


routine 
independently 
anywhere 
in memory. 


The two programmable 
timers 
may be used 
to 


generate real-time clocks by requesting periodic inter- 
rupts 
through 
the PIC, so that 
the CPU is free to 


handle 
numerous 
other 
system-timing 
and control 


functions. The outputs and gate/trigger 
inputs of the 


timer7counters 
can be routed via jumpers 
to the PIC, 


the 
I/O 
driver/terminators, 
or the 
programmable 


parallel 
I/O. 


Seven 
software-selectable 
timing/counting 
func- 


tions are available. Either timer may be set to act as 
a rate generator 
(divide-by-N counter), a square-wave 


4. Byusing the RMX·aO executive and the library of often- 
used subroutines. program development can be simplified 
since the subroutines 
are modular and can be linked 


together. then checked out in a system prototype. 
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ADAC Corp.. 118 Cummings Park. 
• 
Woburn. MA 01801.(617) 935-6668 
451 
Ampex, Memory Products DiV6 


200 N. Nash St., 
• 
452 
EI Segundo, CA 90245.(213) 
40-0150 


Analog Devices, Route 1 Industrial Park, 
• 
453 
P.O. Box 280, Norwood, MA 02062.(617) 
329-4700 
AUf-at Inc., 33 Pera Ave'Ll-O- Box 779, 
• 
Att ebaro, MA 027 3.(61 ) 222-2202 
454 
Burr-Brown, International Air~rt 
Indus¥lal Park. 
• 
P.O.Box 11400 Tucson, AZ 
5734.(602 
294-1431 
455 
Cybernetic MicrOS6jtems, 2460 Embarcadero Way, 
• 
• 
456 
Palo Alto, CA 943 3.(415) 321-0410 
Data Translation Inc.• 23 Strathmore Road, 
• 
Natick, MA 01760.(617) 655-5300 
457 
Datacube Corp., 25 Industrial Park, 
• 
Chelmsford. MA01824_ (617) 256·2555 
458 
Datel Systems Inc., 1020 Turnpike St., Building S., 
• 
Canton, MA 02021.(617) 828-8000 
459 


Digidata cogb 
8580 Dors1fl Run Road. 
• 
Jessup.MD 
0 94.(301) 4 8-0200 
460 
EDACCorp.. 1417 San Antonio Ave.. 
• 
Alameda, CA 94501.(415) 521·6600 
461 
Electronic Engineering & Prod_Services, TE. #2, 
• 
louisville, TN 37777. (615) 984·9640 
462 
Electronic Solutions. 7969 En~ineer Rd.. 
• • 
• 
San Diego, CA 92111.(714) 2 2-0242 
463 
Garry Mfg. Co., 1010 Jersey Ave., 
• 
New Brunswick, NJ 08902.(201) 545-2424 
464 


Hal Communications Corft, Box 365B, 807 E. Green St., 
• 
Urbana, IL 61801.(217) 
67-7373 
465 
lasis, 815 W. Maude Ave., 
• 
Sunnyvale, CA 94086. (408) 732-5700 
466 
ICOM, 6741 Vanel Ave.. 
• 
Canoga Park, CA 91303(213) 
348-1391 
467 


Megalo~ic Corp., 9650 National Road, 
• 
Brookvi Ie, OH 45309.(513) 833-5222 
468 
Micro Memories Inc., 9438 Irondille Ave.. 
• 
Chatsworth.•CA 91311.(213) 998-0700 
469 


Microtec, P.O.Box 60337. 
• 
Sunnyvale, CA 94088.(408) 733-2919 
470 
Monolithic Systems Inc., 14 Inverness Drive, 
• • 
East, Englewood, CA 80110.(303) 770·7400 
471 


~allonal Semiconductor, 2900 Semiconductor Drive, 
• 
Santa Clara, CA 95051.(408) 737-5000 
472 


North Star Computers·lnc, 
2465 Fourth St, 
• 
Berkeley, CA 94710. (415) 549·0858 
473 


The Thomas En~ineeri1: Co.• 1201 Park Ave., 
• 
Emeryville. CA 
4608.( 
15) 547·5860 
474 


Vector Electronic Products, 12460 Gladstone Ave.. 
• 
Sylmar, CA 91342,(213) 365-9661 
475 


Zia Tech., 10762 La Roda Drive. 
Cupertino, CA 95015.(408)996 
-7082 
• 
476 
, 


generator, 
a programmable 
retriggerable 
one-shot, or 


software 
or hardware-triggered 
strobe. 
One of the 


timers 
can be jumper-selected 
as an event counter, 


and either can generate 
an interrupt 
after a specified 


interval 
or after 
a specified number 
of events. 


The programmability 
of each on-board timer allows 


timing intervals 
from approximately 
2 /lS to over 60 


ms. But the two timers 
may be cascaded to provide 


intervals greater than 1.1 hour, in 1.86/ls increments. 
In the event counter 
mode, external 
event rates 
up 


to 1.1 MHz may be counted. 


Flexible I/O, a must for any system 


All SBC-80 microcomputers 
provide 22 or 48 pro- 
grammable 
parallel 
I/O lines that, grouped as 8-bit 


ports, are fully programmable 
to allow enough flex- 


ibility to handle any changes in system 
interfacing. 
Programmability 
is permitted 
through data direction, 


control 
mode, 
interrupt 
handling, 
and 


buffer/termination. 
The I/O configuration 
for a spe- 


cific 
application 
is selected 
through 
software 
in- 


itialization 
of the parallel 
I/O control logic, jumper 


selection 
of control/interrupt 
line routing, 
and the 
particular 
buffer 
and termination 
devices chosen. 
Fig. 3 illustrates 
the basic modes of operation 
that 


may 
be selected 
by software 
to meet 
application 


requirements. 
Mode 0 is used for slow-to-medium- 


speed 
interfacing 
where 
immediate 
handshake 
re- 


spor.se or interrupt 
generation 
is not needed. This 


mode is extremely useful for interfacing to inputs such 
as switches 
or outputs 
such as LED indicators 
or 


numeric 
displays. 
Mode 1 provides 
handshaking 
lines required 
for 


many 
medium 
to high-speed 
peripherals. 
A typical 


output function could be a line printer; an input device 
could be an encoded keyboard 
or paper tape reader. 
In addition, 
the 80/l0A 
and 80/20 have Mode 2, a 


bidirectional 
data/control 
structure. 
This interface 


may 
provide, 
for 
example, 
a communication 
link 


between 
parallel 
processors. 


The SBC-80 I/O structj.lre 
also permits 
multiple 
options for output 
buffering 
and input termination. 
TIL drivers 
with 16 to 48 mA of drive can be used, 
and input lines may be terminated 
to minimize the 


impact of noise and cable disconnects. Any of the TIL 
drivers (four outputs) or input terminators 
(for inputs) 


listed in Table 6 may be inserted into sockets to provide 
proper 
buffering 
or termination. 
Like the design flexibility of the SBC-80 parallel I/O 


structure, 
the serial 
I/O structure 
allows interface 


characteristics 
to be revised rapidly through software, 
jumper, and buffer changes. Besides the SBC-80/10A, 
the 
80/20 
and 
80/20-4 
contain 
the 
USART 
serial 


channel. These boards provide RS-232 interfaces, 
but 


the SBC-80/10A also has a teletypewriter 
current-loop 


interface. Synchronous/asynchronous 
mode, data for- 


mat, 
control-character 
format, 
and 
parity 
are 
all 


under program 
control. So is baud rate on the 80/20 


and 80/20-4. Baud rate 
is jumper-selectable 
on the 


AACK 
Advance-acknowledge 
signal, 
used 
in 


8080A-based systems. It is sent to the 
SBC-SOboard by a memory bank in re- 
sponseto a mj!mory-read command, allow- 
ing the memory to complete the access 
without requiring the CPU to wait. 


BCLK 
Busclock, usedto synchronize bus-control 
circuits on all master boards. It hasa period 
of 101.725ns(9.8304 MHz)and a 30to 70% 
duty cycle. The signal may be slowed, 
stopped or single-stepped. 


BPRN 
Bus-priority-input signal, usedto indicate to 
the master that a higher-priority 
master 


board wants to use the system bus. When 
brought high, the signal suspendsprocess- 
ing activity and places line drivers of the 
master in a standby mode. 


BUSY' 
Bus-busysignal, a bidirectional control line 
that allows control and monitoring of the 
Multibus in multimaster 
s~tlstrs. 
As an 


output from a bus master, 
indicates 


the bus is being used by the board. It 
preventsall other master boards from gain- 
ing 
control 
of 
the 
bus. 
Each master 


monitors OOSY as an input to determine 
current Multibus usage status. 


CCLK 
Constant clock, used to provide a 9.8304- 
MHzclock signal for o~~Lnal memory and 
I/O expansion boards. 
K coincides with 


Bcr"R and has a period of 101.725 ns and 
a 30 to 70% duty cycle. 


INIT 
Initialize signal, used to reset the entire 
system to a known internal state. 


INTRI 
Interrupt input. used to interrupt the proc- 
essor via an externally generated interrupt 
request. 


10RC 
I/O-read command, a signal generated by 
the master to indicate that the address of 
an input 
port 
has been placed on the 


system-address bus and that the data at 
that input port are to be read and placed 
on the system-data bus. 


10WC 
I/O-write command, a signal generated by 
the master to indicate that the address of 
an output 
port has been placed on the 


system-address bus and that the contents 
of the system-data bus are to be output to 
the addressed port. 


MRDC 
Memory-readcommand, a signal generated 
by the master that indicates that the ad- 
dressof a memory location hasbeenplaced 
on the system-addressbus. It specifies that 
the contents of the addressed location are 
to be read and placed on the system-data 
bus. 


MWTC Memory-write command, a signal gener- 


ated by the master to indicate that the 
address of a memory location has been 
placedon the system-addressbus. It causes 
information on the data bus to be written 
into the addressed memory location. 


XACK 
Transfer-acknowledge signal, an input sig- 
nal to the master board from an external 
memory location or I/O port to indicate that 
a specified read or write operation hasbeen 
completed. 


SO/lOA CPU board. 
The synchronous 
and asynchronous 
nature 
of the 


serial 
interface 
makes 
it compatible 
with virtually 
every 
standard 
serial 
data-transmission 
technique 


used today 
(including 
IBM's Bi-Sync). This allows 
multiple 
SBC-SO boards 
to be interconnected 
as a 


distributed-processing 
network. 
The resulting 
task 


segregation 
or redundancy 
(or both) 
significantly 
improves 
both system 
performance 
and reliability. 
Two jumper-selectable 
interrupt 
requests 
may be 
generated 
automatically 
by the serial interface. 
One 


occurs when a newly received character 
is ready to 


be loaded into the CPU (receive-channel buffer is full). 
The other 
occurs when 
new data 
are ready 
to be 
transmitted 
to the remote device (transmit-data 
buf- 


fer is empty). 
Both the SBC-SO/04 and SOlOS provide serial 110 
capability 
through 
the serial 
input 
data (SID) and 


serial output 
data (SOD) functions 
of the SOS5CPU. 
These functions are controlled by software executing 
the SOS5read-interrupt 
mask (RIM) and set-interrupt 


mask (SIM) instructions. 


For systems 
requiring 
many serial channels, 
the 


SBC-534 communications-expansion 
board 
provides 
four USART channels 
with RS-232-C and optically 
isolated current-loop 
interfaces, 
programmable 
inter- 


rupt, timing, baud-rate 
control, and a Bell SOl Auto- 


Call unit interface. 


Expand the system 
via the Multibus 


The SBe-SO family is gaining not only in popularity 
but in support 
for its Multibus 
as more and more 


companies 
offer SBe-compatible 
boards. 
Intel 
now 
provides 
high-speed 
mathematics, 
RAM, EPROM, 


mass storage, digital 110, combination 
memory and 


I/O, serial communications, 
and analog-I/O expansion 


boards. 
For 
applications 
requiring 
fast, 
high-precision 


number crunching, 
the SBe-310 math unit acts as an 


intelligent 
slave to perform floating-point 
and fixed- 


point 
mathematics. 
A processor 
uses 
the 
310 by 
passiflg parameters 
to it along with a command byte 
to select the desired operation from the SBC-31O's 14 
.instructions. 
The repertoire 
includes 32-bit floating- 


point (single-precision) 
addition, 
subtraction, 
multi- 


plication, 
division, 
squaring, 
square 
root, 
com- 


parisons, 
and tests; 16-bit fixed-point 
multiply, 
sub- 


tract, 
extended 
divide, and extended 
compare; 
and 


conversion from fixed to floating point or vice versa. 
A completed operation 
may be signaled either by 
the 
math 
unit 
via 
an 
interrupt 
or 
by the 
host 


processor's polling the "operation complete" flag in the 
unit's status 
register. 
The result may be retrieved at 


this point or left in the 31O'saccumulator 
for further 


use. 
In addition, the 310 provides control circuitry so that 


it may be treated as a "shared resource" among several 
CPU boards. 
Two diskette options are available for mass storage. 


Table 5. Programmable interrupt 
modes,SBC-80/2Q.4 


Mode 
Operation 


Fully nested 
Interrupt request line prior- 
ities fixed at 0 as highest. 7 
as lowest. 


Autorotating 
Equal priority. Each level, af- 
ter 
receiving 
service, 
be- 


comes the 
lowest priority 


level until next interrupt oc- 
curs. 


Specific priority 
System software assignslow- 
est priority level. Priority of 
all other levels based in se- 
quence on this assignment. 


,",oiled 
System software examines 
priority-encoded 
system in- 


terrupt 
status via interrupt 


status register. 


Line drivers 


Driver 
Characteristic 
Sink current (mA) 


7438 
I.OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


Note: 
I "" inverting; 
NI 
"" nonmverting: 
DC 
•• open 
collector 


5V; 
..y 


~ 
INTEL see901 


220 
A4 
•. 
330 
--- - -- - -- ---- -------------- 
----- 


5VO 
..., 
o INTEL 
SBe 
902 


Ik 


The SBe-201 diskette controller 
provides full control 


for one or two single-density 
diskette drives and acts 


as a programmable 
slave to masters on the Multibus. 


All diskette 
information 
is stored 
in the IBM soft- 
sectored 
format. 
For 
systems 
requiring 
greater 
storage capacity, the SBC-202 provides full control for 
up to four double-density 
diskette 
drives. 
Thus, 
2 


Mbytes of mass storage may be added to SBC-SO-based 
systems 
for each SBC-202 plugged into the bus. 


Digital 1/0 may be expanded using any of three Intel 


boards. The SBC-519 provides 72 programmable 
par- 


allel I/O lines as well as interrupt 
handling and a real- 


time clock. 


The 519's clock can interrupt 
the appropriate 
CPU 


periodically so that the CPU can monitor system-I/O 
status. 
High-speed 
1/0 events 
can gain the CPU's 
attention 
via interrupts. 
The SBC-517 combination 


I/O board and the SBC-104, lOS and 116 combination 
memory and 110 boards offer 4S programmable 
par- 


allel 
lines, 
a full 
RS-232 USART 
serial 
channel, 
interrupt 
handling 
and a 16-ms real-time 
clock. The 


3-210 
AFN.()193,A 


Provides 
basic 
capabilities 
(concurrence. 
priority, 
and 
synchroniza- 


tion/communication) 
found 
in all real-time 
systems. 


Provides real-time 
asynchronous 
I/O between an operator's 
terminal 
and tasks 


running 
under 
the RMXl80 
executive, 
includes 
a line-edit 
feature 
similar 
to 


that 
of ISIS-II (supervisory 
system 
on the Intellec 
development 
system) 
and 


type-ahead 
facility. 


Diskette 
driver 
and file 
management 
capabilities. 
allows 
user to load tasks 


into 
the 
system 
and 
to 
create. 
access, 
and 
delete 
files 
in 
a 
real-time 


environment 
without 
disrupting 
normal 
processing. 
File formats 
compatible 


with 
ISIS-II for 
both 
single 
and 
double-density 
systems. 


, 


Maintains 
a pool 
of free 
RAM and allocates 
memory 
out 
of the 
pool 
upon 


request 
from 
a task; 
reclaims 
memory 
areas when 
no longer 
needed. 


Specifically 
designed 
for 
debugging 
software 
running 
under 
the 
RMXl80 


executive; 
used by linking 
it to an application 
program 
or task. Thus, 
it can 


be run 
directly 
from 
the single-board 
computer's 
memory. 


Provides 
full 
control 
and communication 
for sse 310 math 
board 
for 
high- 


speed fixed 
and floating-point 
math 
functions. 


104, 108 and 116 also hold up to 8 kbytes of EPROM, 
along with 4, 8 or 16 kbytes of RAM, respectively. 


For systems 
geared 
to especially 
noisy environ- 
ments, the SBC-556 provides 48 optically isolated I/O 
lines, which are configured as 24 input lines, 16output 
lines, and eight programmable-I/O 
lines. The user 
fixes the optical-isolation 
characteristics 
according to 
his exact system requirements 
by installing the opto- 


isolators 
and current-limiting 
resistors 
of his choice 
into the board sockets. 
Input 
voltages 
up to 48 V, 
output lines up to 30 V and currents 
up to 60 mA may 
be interfaced. 
Of course, many more RAM, ROM, communications 
and interface 
options are available. 
But for systems 
to come together 
quickly during development, 
there 
must 
be some standardized 
operating 
software 
to 
provide some of the most fundamental 
system 
rou- 
tines. 


System 
software: 
the glue that 
binds 


Where the Multibus provides a standard 
hardware 
structure, 
RMX-80, a real-time multitasking 
executive 
supplies 
a 
modular 
software 
framework. 
With 
RMX-80, routines don't have to be developed for task 
synchronization, 
priority 
resolution 
and peripheral 
control (printers, 
terminals, 
diskettes, 
etc.). Versions 


are available for the SBC-80/20, 80/20-4 and 80/l0A 
CPU boards. 
Critical projects can be completed rapidly because 


RMX-80 provides 
major 
portions 
of the 
software 


requirements 
for many real-time systems. For exam- 


ple, the diskette file-extension software of the RMX-80 
program 
may be linked into the system 
software. 


Thus, 
users 
can 
immediately 
have 
a diskette 
file 


structure 
with facilities to open and close files, create 


and delete files, read or write 
files sequentially 
or 


randomly 
(read 
function 
may 
be used 
for initial 


program 
load, if desired), 
or allocate 
file storage 


dynamically 
on single or double-density 
diskettes. 


The compactness 
of RMX-80-the 
entire executive 


resides in 2 kbytes of ROM-reduces 
memory require- 


ments and eliminates 
the need for bootstrap-program 


loading. All RMX-80 operations 
are based on individ- 


ual tasks. A task is a program 
with unique data and 


stack that operates 
asynchronously 
with other such 


programs 
in the system. 
Basically, 
the RMX-80 is a library 
of "standard" 


routines (Table 7), such as an analog-interface 
handler 


and 
a terminal 
handler. 
Fig. 4 illustrates 
how to 


develop software 
by selecting 
appropriate 
RMX-80 


modules, then locating and linking them with particu- 
lar 
software 
tasks 
on an 
Intellec 
microcomputer 


development 
system. In addition, a debugger module 
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5. This 
possible 
SBC·80 
system 
configuration 
uses four 


SBC-80/05s 
to monitor 
and control 
pipeline 
parameters 


in the RMX-80 speeds real-time system development. 


The executive accesses system resources according 


to task priority, 
intertask 
communication, 
interrupt- 


driven control for standard 
devices, real-time 
clock 


control, interrupt 
handling, 
and other optional func- 


tions. In all, there are 255 separate task-priority 
levels, 
and since multiple 
tasks may share the same level, 


the actual number of tasks is limited only by memory 
size. 


Develop 
programs 
with the Intellec 


The Intellec and its ICE-80 and ICE-85 in-circuit 


emulators 
help minimize the time required to develop 


software and hardware. Standard 
Intellec stand-alone 
software 
includes resident 
macroassemblers 
for the 


8080A and 8085 CPUs, a text editor, and a system 
monitor/debugger. 
As a result, 
programs 
can 
be 


assembled, 
loaded, edited, executed, 
and debugged. 
ICE diagnostics 
can significantly 
reduce program 


development 
and debug time. Break points may be 
set on user-specified 
memory-read 
or write opera- 


tions, I/O read or write operations, 
or user-defined 


extension parameters. 
Programs can be single-stepped 


to check operating 
conditions 
and performance. 
PL/M-80 
is the high-level 
systems-programming 


language. 
The optional 
Intellec-resident 
PL/M com- 


piler provides the ability to program 
in this natural, 
algorithmic 
language, so there is no need to manage 
register usage or to allocate memory. PL/M programs 


and feed data back to a master 
controller, 
an SBC-80/20-4. 


The master 
controller 
sends data back to a host system. 


6. 
Expanding 
the pipeline 
monitor/controller 
system is as 


simple 
as plugging 
more 
cards 
into 
the 
Multibus 
and 


altering 
the software. 
By adding 
another 
SBC-80/20 
to the 


master 
controller, 
some local processing 
can be done and 


a local 
CRT and high-speed 
printer 
can be added 
as well 


as RAM and 
diskette-memory 
space. 


may 
be linked 
to assembly-language 
programs 
to 


hasten 
product 
development 
further. 


A relocatable 
macroassembler 
residing 
on the In- 
tellec translates 
symbolic assembly language into 8080 


or 8085 machine 
code and 
permits 
the use of re- 


locatable 
and linkable object code. With full macro 


capability, 
similar sections of code needn't be written 


over and over. 
Intellec options include a diskette operating system, 


ISIS-II, with diskette controller, single or dual diskette 
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including 
a relocating 
macroassembler, 
relocating 


loader and a linker to help link separately 
compiled 


or assembled 
programs. 


Apply 
the SBC 
boards to real use 


To get an idea of the SBC 80 family's capabilities, 
examine the application 
shown in Fig. 5. In this case, 


a remote 
control/monitoring 
section 
of a pipeline 


supervisory 
control 
system 
grows 
with 
increasing 


requirements 
for 
additional 
local throughput 
and 


processing 
capability. 
Four 
SBC-80/05s 
act 
as 
remote 
pipeline 


monitors/controllers. 
Each unit monitors various con- 


tact closures (limit switches, 
relays, etc.) and a hex 


keypad, with a subset of its own I/O lines programmed 
as inputs. Contact debounce is performed in software. 
Other digital I/O lines on each SBC-80/05 act as output 
lines·to drive a numeric display and various control 
relay 
coils. 
Analog-control lines are interfaced with an SBC-732 


combination 
analog-I/O 
board. Transducers 
indicat- 


ing temperature 
and pressure drive analog inputs, and 


analog outputs 
drive valves. Flow rate is determined 


in software 
by manipulating 
differential 
pressure 


data available 
from pressure 
transducers. 


The four 
80/05s are linked serially 
to a remote 


RS-232-C serial 
channels, 
each interfacing 
directly 


with 
one 
of 
the 
.four 
80/05-based 
pipeline 


monitor/controllers. 
The 80/20-4 periodically queries 


each monitor 
to determine 
its current 
status. 
The 


concentrator 
also relays 
control 
commands 
from a 


host computer 
controlling 
the entire 
pipeline. 
The 


80/20-4's own RS-232-C serial channel 
provides the 


interface 
for this high-speed synchronous 
link to the 


host CPU. 


The 80/20-4 can contact the host CPU with the Bell 


801 automatic 
calling-unit 
interface 
on the SBe-534. 


The synchronization 
and control of communication 


between the four 80/05s and the host are handled by 
RMX-80 on the 80/20-4. 


The 80/20-4 system can be expanded to provide local 


processing capability, as shown in Fig. 6. Here, anoth- 
er 80/20 
is added 
as a second master on the Multi- 


bus to provide 
control 
for a local CRT and high- 


speed 
printer, 
and 
to 
provide 
local 
processing 


capability. 


An additional 
32 kbytes of RAM are furnished 
by 


an SBC-032 RAM-expansion 
board. A third 
master, 


an SBC-202 dual-density 
diskette controller, 
can also 


be added to the Multibus, 
along with two double- 


density diskette 
drives. Communication 
between the 


two 80/20s is handled 
via user-written 
intermaster 


message 
tasks .•• 
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SYSTEMS 


Design decision factors involved in developing multiple processor 
microcomputer systems include means of minimizing contention for 
system bus utilization. System applications detail the appropriate 
hardware and software considerations as related to single-board 
computers in a multimaster bus structure 


Large-scale 
integrated 
circuit 
technology has reduced 


the cost of central processors to such a low level that 
the 
previously 
avoided 
concept 
of 
applying 
multiple 


processors to meet system performance requirements 
has 


now become an attractive and viable alternative. Several 
key benefits accrue from such an approach. 
In addition 


to enhanced system performance 
(throughput), 
improved 


system 
reliability, 
and 
improved 
system 
realtime 
re- 


sponse, modular 
system expansion 
capabilities 
may be 


realized. 
Although 
designing 
such 
systems 
"from 


scratch" 
with 
microprocessor 
component 
families 
can 


be a complex system design task with many subtle pit- 
falls which can 
inhibit 
efficient system operation, 
the 


advent 
of 
second 
generation 
single-board' 
computers, 


such as the Intel@ SBC 80/05 
and 80/20, 
has allowed 


multiple 
processor 
microcomputer 
systems to 
become 
off-the-shelf products. 


Discussion of the benefits of multiple processor structures 
in system applications 
will provide an understanding 
of 


the motivation 
for this implementation 
approach 
in sys- 
tem 
design. 
A 
primary 
objective 
addressed 
through 
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multiple processor 
approaches 
is enhanced 
system per- 


formance 
and 
throughput. 
Enhanced 
performance 
is 


achieved through partitioning 
of overall system functions 


into tasks that 
each of several processors 
can handle 


individually. 


In general, 
as the number 
of individual 
tasks 
any 


given processor must handle is reduced, that processor's 
response time to new requests for service will be reduced. 
A well planned 
multiple 
processor 
bus 
structure 
will 


allow new processors 
to be 
added 
to the 
system 
in 


modular fashion. When new system functions 
(ie, more 


peripherals) 
are added, more processing 
power can be 


applied to handle them without impacting existing pro- 
cessor (master) 
task partitioning. 


As used here, a "master" is any element existing on the 


system bus that may take control of the bus (ie, assert 
address 
and 
control 
lines). 
Typical 
examples 
include 


processors and direct memory access 
(DMA) 
controllers 


that address memory and inputjoutput 
(I/O) 
locations 


resident 
on the bus. "Slave" 
elements 
include 
passive 


functions 
on the bus, 
such 
as memory 
or non-DMA I/O 


interfaces. Note that although slaves may possess inteIli- 


Fig 1 
Multiple processor bus structure. Dual onboard/offboard 
structure of MULTIBUS allows each master to use its 


own memory and 1/0 without utilizing 
common system 
bus (a). Only when a master requires access to common mem- 


ory or 1/0 
does it use the bus (b). Note that other masters may 
continue 
onboard operations 
simultaneously 


EXTERNAL 
INTERRUPT 
REQUEST 
LINE 


9 INTERRUPT 
"'""~"." 


Fig 2 
SBC 80/05 
block diagram. 


SSC 80/05 
is a full 
microcom- 


puter 
on a single 
PC board. 
It 


provides 8085 CPU plus RAM for 
program or data storage, EPROMI 
ROM for program 
storage, inter- 


val timer, 
programmable 
parallel 


1/0 
(22 
lines), 
serial 
1/0, 
and 


full 
MULTIBUS 
multi master con- 


trol logic 
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Hardware 
considerations 
must be thoroughly 
evaluated 
in any multiple 
processor 
bus structure. 
These factors 
are described 
in detail around 
a specific implementation 


of such a structure, 
the Intel" 
MULTIBUS™, 
which sup· 
ports 
multiple 
processor 
systems 
with 
its multi·master 
bus structure. 


One architectural 
option open to the system designer 
is 
that 
of a multiple 
master/single 
bus 
structure. 
Under 
this partitioning, 
every master 
utilizes the common bus 
data 
path 
to fetch instructions 
or data 
from 
memory, 
read 
data 
from 
input 
devices, or write 
data 
to output 
devices or memory. 
Therefore, 
the common system bus 
rapidly 
becomes 
the 
bottleneck 
for 
overall 
system 
throughput, 
and fast 
DMA transfers 
can easily approach 
the full bandwidth 
of the bus during 
block transfers 
so 
that 
all other 
masters 
must 
idle for extended 
periods. 


shown in Fig 1. Each processor.based 
master within the 


system 
retains 
its own local memory 
and 
I/O that 
it 


utilizes for most oJ?erations. Such local operations 
occur 


totally on the individual 
board 
and do not require 
the 


system 
bus. 
This 
greatly 
reduces 
the 
service 
request 


frequency by each master requiring 
use of the system bus. 


Such a dual·bus 
structure 
is implemented 
on the SBC 


80/05 
and 80/20 
single-board 
computers, 
as shown in 


Figs 2 and 3, respectively, 
with the multi-master 
system 


bus 
(MULTIBUS) 
.',2 


Access to the system 
bus is requested 
only when a 


global 
(resident 
on the bus and accessible by multiple 


masters) 
memory 
location 
or 
I/O 
device 
is referenced 


during 
an instruction 
execution 
cycle. Local/global 
(on- 


board/offboard) 
distinction 
is defined through the value 


of the physical 
address 
referenced. 
If it lies within 
the 


address range of onboard memory or I/O, no bus request 
is made. 
Only 
when 
the 
address 
references 
a 
global 


USER DESIGNATED 
PERIPHERALS 


48 PROGRAMMABLE 
PARAllEL 
I/O LINES 


2 
INTERRUPT 


REOUEST 
LINES 


Fig 3 
SSC 80/20-4 block diagram, SSC 80/20-4, also a lull microcomputer on a single PC board, provides 8080A-2CPU, 


4k bytes 01 RAM,up to 8k bytes 01 EPROM/ROM,48 programmable I/O lines, three interval timers, lull RS-232-C serial 
port, 8-level priority interrupt logic, and MULTISUS multimaster control logic 


memory or I/O location, is a system bus request initiated. 
If no other 
master 
is currently 
utilizing 
the bus, this 


"new" master will be granted 
access immediately. 
How. 


ever, this new master 
must wait if another 
master 
is 


currently utilizing the system bus. It continues to monitor 
the status of the system bus to determine 
when its cur- 


rent cycle may be completed. Thus, the 
MULTIBUS 
must 


provide a method for masters to determine 
whether or 


not another master is currently 
utilizing it. 


Other 
masters 
may 
also simultaneously 
request 
the 


system bus. Arbitration 
must then be performed 
to re- 


solve this multiple contention 
for the system bus. The 


MULTIBUS 
structure 
provides 
this arbitration 
in one of 


two techniques: 
serial 
(daisy 
chain) 
or 
parallel 
(en- 


coded). 
The structure consists of four control lines that 


are synchronized 
by the common bus clock. These four 


control 
lines and the bus clock are active low. This is 


represented 
by the slash 
(I) 
character 
after each signal 


mnemonic. Control lines are as follows: 


Bus Clock 
(BCLK/) 
-The 
negative edge of BCLK/ 
is 


used to synchronize bus arbitration. 
BCLK/ may be asyn- 


chronous to all CPU clocks, and it has a loo·ns minimum 
period. 
BCLK/ 
may 
be 
slowed, 
stopped, 
or 
single. 


stepped for debugging. 


Bus 
Priority 
In 
Signal 
(BPRN/)-Indicates 
to a par· 


ticular master that no higher priority 
master is request- 
ing use of the system bus. 


Bus Priority 
Out Signal 
(BPRO/)-Used 
with serial bus 


priority 
resolution 
scheme. BPRO/ 
is passed to BPRN/ 


input of master with next lower bus priority. 


Bus Busy 
Signal 
(BUSY/)-Driven 
by bus master cur· 
rently 
in control 
of 
MULTIBUS 
to indicate 
that 
bus is 


currently 
in use. BUSY/prevents 
all other masters from 


gaining 
control of bus. 


Bus Request 
Signal 
(BREQ/)-Used 
with parallel 
bus 


priority 
network to indicate that a particular 
master re- 


quires use of the bus for one or more data transfers. 


Serial (Daisy-Chain) 
Bus Arbitration 


In a serially 
arbitrated 
MULTIBUS 
system 
(Fig 
4) 
reo 
quests for system bus utilization 
are ordered by priority 


on the basis of bus location. 
Each master 
on the bus 


notifies the next lower priority 
master when it needs to 


use the bus for a data transfer, 
and it monitors the bus 


request status of the next higher 
priority 
master. 
Thus 


the masters pass bus requests along from one to the next 
in a daisy-chain 
fashion. 


The highest priority 
master 
(Master 1) in the system 
will always 
receive access to the system bus 
when it 
requires it. There is no higher priority 
master to inhibit 
its bus requests, and its bus priority 
input line (BPRN/) 


is thus permanently enabled. 


Masters operate 
asynchronously 
on the 
MULTIBUS. 
A 


master may thus be in the middle 
of a bus operation 


when a higher 
priority 
master 
requests 
the bus. 
Ob. 


viously, 
interruption 
of such an in·process cycle must 


not 
be 
allowed. 
The 
mechanism 
for 
avoiding 
such 


erroneous 
operation 
is the 
BUSY/ 
line. 
Upon 
being 


notified that 
access to the bus is possible, the master 


examines 
BUSY/. 
If this control 
line 
is inactive, 
the 


master 
will assert 
it, and complete 
its bus operation. 


If BUSY/ is already active, another 
master is currently 


using 
the bus. In this case, the master 
will examine 


BUSY/ 
upon 
every 
falling 
edge of BCLK/, 
typically 


once every 
100 ns, 
until 
it 
becomes 
inactive. 
When 


BUSY/retums 
to its inactive state, the master will assert 
it, then complete its operation. 
The BUSY/line 
then in- 


hibits 
higher 
priority 
masters 
from 
destroying 
a bus 


transfer 
cycle that may be already 
in progress. 


The BUSY/ 
line 
is also controlled 
by 
a bus 
lock 
function 
on the SBC 80/0S 
and 80/20. 
This 
function 
allows a master, which currently 
has control of the bus, 


to 'retain control by independently 
asserting the BUSY/ 


line 
until 
it issues an 
unlock 
command 
that 
releases 


BUSY/. 
This permits 
a bus master 
to obtain exclusive 
control of the system bus for critical 
system functions, 


Fig 4 
Serial bus arbitration. When any master 
requires use of MULTIBUS in serial (daisy-chain) 
priority mode, its BPROI line inhibits lower prior- 
ity masters from system bus utilization. BUSYI 
line is used to ensure that in-process operations 
of lower priority masters are not destroyed by 
asynchronous 
bus 
requests 
of higher 
priority 


masters 


such 
as high 
speed 
memory 
or 
I/O 
data 
transfers 
and 


critical 
read-modify-write 
operations_ 
With 
BUSY/ 
asserted 
in this way, all other 
masters 
will find the bus 
"in use" when they attempt 
to access it. Whereas 
system 


bus transfers 
normally 
take place on an interleaved 
basis 
(bus 
arbitration 
performed 
for 
each 
cycle J, 
this 
bus 
lock function 
permits 
fast multiple-word 
transfers, 
when 


needed. 
Two basic parameters 
determine 
the number 
of masters 
that can coexist 
on the system bus in serial 
bus arbitra- 


tion 
mode. 
These 
are 
the 
BCLK/ 
cycle 
time 
and 
the 
BPRN/ 
to BPRO/ 
propagation 
delay 
of bus 
masters. 
Masters may be added to a system as long as the cumula- 
tive BPRN/ 
to BPRO/ 
propagation 
delay is such that the 


lowest priority 
master 
will always 
have 
its BPRN/ 
line 
driven 
inactive 
before the next BCLK/ 
falling edge after 


the highest 
priority 
master 
requests 
the bus. This 
worst- 


case 
timing 
condition 
is met 
as long 
as the 
following 
relationship 
is satisfied. 


N-l 
:E (lHr'K",-KI'RO) 
I < tnnK 
- 
t~h 
i=l 


where 


(tRI'R'i'_JII'RO) 
I = Propagation 
delay 
for master 
i 


I"'LK = Bus clock (BCLK) 
cycle lime (period) 
t.h = Allowance 
for bus 
setup 
and 
hold 
times 


N = Number of bus masters 


Using 
serial 
bus 
arbitration 
and 
SBC 
80 
onboard 


clocks, 
up to three 
masters 
may 
coexist 
on the 
system 


bus. This number 
can easily be extended, 
if desired, 
by 
generating 
a BCLK with a longer 
cycle. The SBC 80/05 
and 
80/20 
provide 
a jumper 
option 
which 
allows 
the 
onboard 
BCLK/ 
to be disabled. 
This 
allows the system 


designer 
to generate 
BCLK/ 
externally. 


Parallel (Hardware-Encoded) 
Bus Arbitration 


The 
parallel 
bus 
arbitration 
technique 
resolves 
system 


bus 
master 
priorities 
using 
external 
hardware. 
The 


parallel 
multi master 
control 
line 
(BREQ/J 
comes 
into 


force 
in this case. Each 
master 
asserts 
BREQ/ 
when 
it 


requires 
access 
to the 
system 
bus. 
These 
lines 
are 
fed 


to 
a 2-chip 
parallel 
priority 
network. 
As 
with 
serial 


priority 
resolution, 
BPRN/ 
acts as the bus access enable 


input 
to each 
master. 
As Fig 5 illustrates, 
up to 'eight 


master 
priority 
levels are encoded 
by a 74148 
priority 


encoder 
to a 3-bit code representing 
the highest 
priority 


master 
currently 
requesting 
the 
system 
bus. 
This 
code 


drives 
the 8205 3-to-8 decoder 
which 
asserts 
the proper 


BPRN/ 
line 
low 
to 
grant 
bus 
access 
to 
the 
highest 


priority 
master. 
The 
74148/8205 
propagation 
delay 
is 


less than 40 ns, easily fast enough 
to allow eight masters 


to coexist 
in this configuration 
utilizing 
a BCLK/ 
with 


a 100-ns period. 
Systems requiring 
up to 16 masters may implement 
bus 


arbitration 
by utilizing 
two 74148 priority 
encoders 
and 


two 8205 
decoders 
to provide 
a 16·level 
hard ware 
pri- 


ority network. 
The actual number 
of bus masters 
feasible 


on the system bus will also depend 
on bus drive, loading 


considerations. 
Even 
under 
this 
consideration, 
systems 


containing 
up to 16 masters 
are feasible. 


Thus, 
single·board 
computer 
masters, 
in conj unction 


with the MULTIBUScontrol 
structure, 
provide 
off-the-shelf 


hardware 
solutions 
for the development 
of efficient multi- 


ple processor 
microcomputer 
systems. 
In addition 
to this 


hardware 
capability, 
the 
system 
designer 
needs 
to con- 
sider 
several 
software 
design 
issues. 


Several 
software 
operations, 
such 
as mutual 
exclusion, 


communication, 
and 
synchronization, 
are 
essential 
to 


proper 
multiple 
proce~sor 
system 
operation. 
The 


MULTIBUS/SBC 80 functions 
that 
enable 
these 
software 


operations 
are examined. 


Mutual Exclusion 


In a multiple 
processor 
microcomputer 
system, 
there are 


Fig 
5 
Parallel 
bus 
arbitration. 
Under 
parallel 
bus 


arbitration 
structure, 
multiple requests 
for access 
to 


the 
MULTIBUS are 
determined 
by 2-chip 
hardware 


priority network. When simultaneous 
multiple bus re-- 


quests occur, only highest priority master has its bus 
grant (BPRN/) line asserted. 
BUSY/line 
inhibits other 


masters 
from interfering 
with system 
bus 
cycles 
in 


progress 


a mecnanlsm 
to guarantee 
that 
asynchronous 
access 
to 
those resou rces is controlled 
in order 
to protect 
data 
from 
simultaneous 
change by two or more processors. 
Thus, some form of mutual exclusion must be provided 
to enable one processor 
to lock out access of a shared 
resource 
by other 
processors 
when it is in a critical 


section. A critical 
section is a code segment that 
once 
begun 
must 
complete 
execution 
before 
it, or 
another 


critical 
section that accesses the same shared 
resource, 


can be executed. 
A Boolean variable 
can be used to indicate 
whether 


a processor 
is currently 
in a particular 
critical 
section 


(true) 
or not (false). 
Testing and setting this variable 


also presents 
a critical 
section. This 
function 
must be 


performed 
as a single indivisible operation; 
if it is not, 
two or more 
processors 
may 'test the variable 
simul. 


taneously 
and then each set it, allowing them to enter 


the critical section at the same time. Such simultaneous 
entry 
would destroy 
the integrity 
of data 
and control 


parameters 
in global memory or cause erroneous double 


initialization 
of a global peripheral controller. 


Mutual exclusion 
can be implemented 
as a software 


function alone, as described 
by Dijkstra" 
for n proces- 


sors operating 
in parallel. 
The SBC 80/05 
and 80/20 


bus lock function 
mentioned 
earlier 
provides 
a means 


for using program 
control to simplify mutual exclusion. 


While the system bus is locked, the master can perform 
the indivisible 
test and 
set operation 
on the Boolean 


Communication 
is an essential 
function 
that 
allows a 


program 
executing on one processor to send or receive 


data 
from a program 
executing 
on another 
processor. 


Typically, 
two processors 
communicate 
through 
buffer 
storage 
in 
common 
memory. 
One 
program, 
called 
a 


producer, 
adds data to buffer storage; 
another, called a 


consumer, removes information 
from buffer storage. 


In 
a 
typical 
application, 
one 
master 
may 
produce 


buffers of data that are to be consumed by a program 
executing 
on another 
master 
that 
services 
an 
output 
device. Communication 
through 
buffer storage 
requires 


the operations 
of adding 
to and 
taking 
from 
buffers. 


These operations 
constitute 
critical 
sections that can be 


controlled 
by providing 
mutual 
exclusion 
around 
the 


buffer manipulation 
operations. 


Synchronization 


At times there is a need for one master to send a syn- 
chronization signal to another. In a sense, synchronization 
is a special case of communication 
during 
which 
no 


data is transferred. 
Rather, the act of signaling 
is used 


to "wake 
up" a program 
executing 
on 
another 
master. 


A program may "sleep," by waiting for a synchronizing 
signal, 
until 
it receives a wake-up signal 
that 
enables 


it to continue execution. Manipulation 
of synchronization 
signals requires mutual exclusion. 


Fig 
6 
Multiple processor 


communication 
application. 


Multiple processors 
may be 


utilized to increase throughput 
in 
system 
requiring 
several 


high speed 
serial 
channels. 


sse 
80/05 
single-board com- 


puter controls four RS-232-e 
or 20-mA serial channels in- 
terfaced 
to 
system 
through 


sse 
534 communication ex- 


pansion board. Second single 
board computer (SSe 
80/20) 


retrieves 
data 
records 
con- 
structed 
by sse 
80/05 
and 


performs further processing 


System Initialization 


In a microcomputer 
system that has multiple processors 


sharing 
a common 
system bus, 
a system initialization 
mechanism must be designed to set up the variables that 
control 
access to the shared 
resources. 
All single-board 


computers 
on the 
MULTIBUS 
begin 
execution 
simulta- 


neously following a system reset. The bus lock function 
of the computers can be used by one specifically desig- 
nated master to lock the bus immediately 
upon system 


reset and to perform 
system initialization 
for common 
resources 
before 
any 
other 
master 
attempts 
to 
access 
them. Since a locked bus has no effect on a single-board 
computer that is executing out of its local memory and 
using its local I/O, normal initialization 
by each processor 


can proceed while the shared resource initialization 
takes 


place. 


Multiprocessor 
Applications 


Two applications 
that 
are well suited 
to multiple 
pro- 


cessor microcomputer 
systems are examined. 
The 
first 


provides 
increased 
throughput, 
and 
the 
second 
allows 


shared 
resources. 


Increased Throughput 


Consider a system that is controlling multiple high speed 


serial communication 
channels in addition to other data 


processing 
activities. 
In this 
case, multiple 
processors 


may be utilized to increase system throughput. 
Such a 


system with 
four 
full-duplex 
serial 
channels 
operating 


at 4800 baud 
could produce 
interrupts 
every 250 
/'S. 


Interrupts 
at that 
frequency 
in a single master 
system 


would leave little time for 
other 
processing 
activities. 


In a multiple processor 
approach, 
one processor can be 


used to handle the interrupts 
from the serial channels, 


accumulate 
data 
into 
records; 
and then 
provide 
those 


records 
to another 
processor 
by placing 
them in com- 


mon 
memory. 
The 
second 
processor 
is not 
burdened 


with 
the overhead 
of handling 
each 
character 
on 
an 


interrupt-driven 
basis, 
instead 
it is sent entire 
records 


of data available for further 
processing. 


As shown in Fig 6, this application 
can be handled 


on the 
MULTIBUS 
with 
four 
boards. 
The 
SBC 80/05 


single-board 
computer 
is used to' service the communi- 


cation board and prepare 
the data records. A 4-channel 


serial communication 
board 
(SBC 534) 
is used to pro- 


vide the hardware 
interface 
for four serial communica- 


tion channels. The SBC 80/20 
single-board 
computer 
is 


used to process data records prepared by the SBC 80/05. 
Common 
memory 
is provided 
by 
the 
SBC 016 
16k 


random-access 
memory 
(RAM). 
Application 
of multiple 
processors 
to this 
problem 


requires 
communication 
through 
buffer 
storage. 
Two 


primitive 
operations, 
introduced 
by 
Dijkstra\ 
can 
be 


used to simplify the communication 
and synchronization 


between the masters. These primitives, 
designated 
P and 


V, 
operate 
on 
non-negative 
integer 
variables 
called 


Fig 7 
Multiple processor 


shared-resource 
a pplie a- 


tion. 
MULTIBUS multiple 


processor 
structure allows 


two 
independent 
single- 


board computers to share 
common 
system 
resource, 


such as an sac 
310 high 


speed math board, to per- 
form floating point opera·· 
tions 


semaphores. 
The 
V 
procedure 
increments 
the 
sema- 


phore 
(5) 
in a single 
indivisible 
operation. 
To make 


certain 
that 
fetch, 
increment, 
and 
store 
are not inter- 


rupted 
by another 
processor, 
the bus is locked during 


the operation. 


Procedures 
for P and V primitive 
operations 
can be 


implemented in 
PL/M6 
as follows: 


V, 


PROCEDURE 
(SIADRl; 
DECLARE 
S BASED 
SIADR 
BYTE; 


OUTPUT(BUSJLOCKl 
= LOCK; 
S = S+I; 
OUTPUT<BUSILOCK) 
= UNLOCK; 


END 
V; 


" 
Lurk 
MI 
1.T1DU!l 
" 


" 
Inl'r~mt'nt 
,~mil.phore 
" 


" 
UnlOl:k 
MULTlBUS 
" 


The P procedure 
loops in a busy wait until 5 is greater 


than 
zero, at which time it decrements 
5. The act of 


fetching, testing, decrementing, 
and storing 5 is also an 


indivisible 
operation. 
Note that 
if several masters 
with 


different 
speeds are in a busy wait on the same sema- 


phore, 
the solution presented 
may not be "fair" 
to the 


lower speed processor; 
that is, the lower speed processor 


would test the semaphore 
less frequently, 
resulting 
in 


an unfair 
advantage 
for higher 
speed processors_ 


Implementation 
of a procedure 
for the P primitive 
is 


shown in the following 
PL/M 
code_ 


P, 


PROCEDURECSIADRl; 
DECLARE 
S BASED 
SIADR 
BYTE; 


DO FOREVER, 
If 5> 
0 THEN 
DO; 


OUTPUT 
CBUSILOCK) 
= LOCK; 


IF S > 0 THEN 


-DO; 
S = S-l; 
OUTPUT<BUSILOCK) 
= UNLOCK; 


RETURN; 


END; 
OIJTPUT<BUSILOCK) 
= UNLOCK; 
END; 


END; 


END 
P; 


" 
Dl"rrem ••nl ~t'maJlh(Jre 
• I 
/' 
Unlock 
MIII.TllIlJS 
'/ 


" 
Elit 
frvm 
P procl"dure 
" 


It is important 
to observe in the program 
listing that 5 


is tested 
prior 
to issuing 
a bus lock. This 
initial 
test 


avoids continuous 
locking and unlocking 
of the system 


bus while looping 
in a busy wait. The second test is 


required because another processor could also have found 
5 greater than zero and tried to enter the critical section 
at the same time. 


With the P and V operations, 
semaphores can be used 


as resource counters in the buffer manipulation 
required 


"for co"mmunication between the 5BC 80/05 
and 80/20. 


For example, a consumer 
program 
can use the P oper- 


ation to decrement 
the number 
of full buffers and a V 


operation 
to increment 
the number 
of empty 
buffers. 


In a similar 
fashion, 
a producer 
program 
can use the 


P operation 
to decrement 
the number 
of empty buffers 


and 
a V operation 
to 
increment 
the 
number 
of full 


buffers. 
In addition 
to full and empty buffer counters, 
it is necessary to maintain 
linked lists pointing to actual 


full and 
empty 
buffers. 
A semaphore 
can be used to 


provide 
mutual 
exclusion 
around 
the manipulation 
of 


the 
linked 
lists. 
In 
the 
example 
that 
follows, 
three 


variables 
(FULL, 
EMPTY, 
and 
SEMA) 
are used to imple- 
ment these functions. 
The two PL/M programs 
illustrate 


consumer 
and 
producer 
code 
segments, 
respectively. 
Note that 
the consumer 
performs 
initialization 
because 


it accesses the semaphores 
prior to the producer. 


CONSUMER, 


DECLARE 
EMPTY 
BYTE 
EXTERNAL; 


FULL 
BYTE 
EXTERNAL; 
SEMA 
BYTE 
EXTERNAL; 
OUTPUTCBUSlLOCKl 
= LOCK; 


EMPTY 
= NUMBIBUFFERS; 


FULL 
= 0; 


SEMA 
= I; 
OUTPUTtBUSlLOCKl 
= UNLOCK; 


DO 
FOREVER; 
CALL 
PCFULLl; 
CALL 
PISEMAl; 


" 
Number 
of emply 
buffen 
" 


" 
Number 
of full 
buffers 
" 


" 
Binary 
semaphore 
" 


" 
Lock 
"fUt.TIBUS 
'/ 


I' Initialize 
semlPho1e, 
" 


" 
Decrement 
full 
buffer 
" 


" 
semaphore" 


" 
Decrement 
mutual 
exclu.ion 
" 


" 
~maphore 
'/ 


(Take 
data 
from 
buffer 
and 


place 
it in local 
memory, 


mo\c 
buffer 
from 
full 
to 


empty 
linked 
list) 


/' 
Increment 
mutual 
exclusion" 


" 
sl'mlphore-' 
,- 
Increm<:nt 
empty 
buffer 
-, 
,- 
st"maphore-' 


END; 


ENO 
CON5U\IER; 


PRODUCER, 


DECLARE 
'EMPTY. 
FULL. 
SEMA) 
BYTE 
EXTERNAL; 


no FOREVER; 


,- 
Decrement 
empty 
buffer 
semaphore 
-, 
,- 
Decrement 
mutual 
eJ:clusion 
-I 


,- 
semaphore-' 


(Place 
dala 
in a huffer, 
move 
buffer 
(rom 
empty 


to full 
linked 
list) 


,- 
Int"rt'ment 
mutual 
exclusion 
-, 


,- 
semaphure-' 


,- 
Increment 
full 
buffer 
semaphore-' 


END; 


END 
PRODUCER; 


Shared 
Resources 


Another 
typical 
application 
for 
a 
multiple 
processor 


microcomputer 
system would be to allow sharing 
of a 


resource hy two processors. 
For example, 
consider 
two 


independent 
processors that have a need for high speed 


mathematical 
functions. Although it may not be possible 


to justify 
a high speed math module 
for each system, 


such a module might be justified if it were to be shared 
by both processors. A multiple processor microcomputer 
system could provide 
the capability 
to allow both pro- 


cessors to share the math module and not interfere 
with 


their otherwise unrelated functions. 


This 
application 
(illustrated 
in 
Fig 
7) 
could 
be 


handled 
with four boards. 
The 5BC 80/05 
single-board 
computer 
is used 
to perform 
various 
data 
processing 


functions requiring 
high speed Hoating-point arithmetic. 


The 5BC 80/20 single.board 
computer controls a process 


where high 
speed numeric 
computations 
are 
required. 


High 
speed 
Hoating-point 
mathematics 
functions 
for 


both single.board 
computers 
are performed 
by an 5BC 


310 high speed math unit. 5BC 116 combination 
memory 


and 
I/O 
board 
provides 
16k 
!lAM, 8k electrically 
pro- 


grammable 
read-only 
memory 
(EPROM), 
48 
parallel 


I/O lines, and an R5-232-C serial port_ 


The problem 
to be solved in this 
application 
is to 


ensure that only one processor has access to the shared 
math 
module 
resource 
at one time. Thus, 
mutual 
ex- 
clusion must be provided 
to control 
the access to the 


resource. 
The 
following 
PL/M 
function 
returns 
TRUE 


if access to a critical 
section, 
used to 
implement 
the 


mutual exclusion, has been granted. 


ENTERtcRrrICALlSECTION, 


PROCEDURE 
1f1.ACIADR) 
BYTE; 
DECLARE FLAC BASED FLACIADR BYTE; 
DECLARE ACCESS BYTE; 
IF FLAC = BUSY THEN 
RETURN FALSE; 
ACCESS = FALSE; 
OUTPUTlBUSILOCKl 
= WCK; 
IF FLAC = NOT BUSY THEN 
DO; 
FLAC = BUSY; 
ACCESS = TRUE; 


~~~~UTlBUSILOCK) 
= UNLOCK; 


RETURN ACCESS; 
" 
Unlock 
MULTI_US 
" 


" 
Return 
either 
TaUI 
or " 


" 
FALSE 
Ieee 
•• 
" 


This 
PL/M 
function 
first 
tests 
the 
flag for 
the 
busy 


condition 
before issuing a busy lock. As in the P pro- 


cedure 
described 
earli~r, 
this 
initial 
test 
avoids 
con- 
tinuous locking and unlocking of the 
MULTIBUS 
while a 


busy wait is being executed. 
The following 
procedure 
performs 
a busy 
wait 
operation 
on the 
flag used 
to 
control access to a critical section. 


BUSYlWAIT, 


PROCEDURE 
IFLACIADR); 


DO WHILE NOT ENTERICRITICALlSECTIONIFLACSADR); 
END; 


END BUSYlWAJT; 


Typical 
code 
segments 
illustrating 
the use of these 
pro- 


cedures follow. 


DECLARE MATHSSOIFLAG 
BOOLEAN EXTERNAL; 
"Flu 
must 
be" 


" 
inilialiud" 


/- 
We could 
.lao 
teal and 
Ihen 
do .orne 
other 
" 


,- 
processin, 
if the 
math 
module 
i. buS)' 
-, 


IF ENTERICRITICALISECTION 
(.MATHIBDIFLAC) 


THEN DO; 


MATHSDO.FLAG:;:; 
NOT BUSY; 
" 
~l 
Rae not bun 
'/ 


END; 


ELSE DO; 


The 
motivations 
for 
implementing 
multiple 
processor 
microcomputer 
systems 
include 
enhanced 
performance 


and 
throughput. 
When 
the 
appropriate 
hardware/soft- 


ware 
design 
considerations 
are 
made, 
modularity 
is 


easily achieved. ~ardware 
solutions 
to many problems 


are 
provided 
by means 
of a 
MULTIBUS 
structure 
and 


SBe 80 single-board 
computers 
that 
have multi master 


capability. 
Through 
control 
of 
MULTIBUS 
functions, 
the 


software designer 
can perform 
multiple processor 
com- 


munication, 
synchronization, 
and mutual exclusion. 


Even with these significant 
steps toward the simplifi- 


cation of multiple processor microcomputer 
systems, the 


design 
of such 
systems 
remains 
a complex 
software/ 


hardware 
design 
task. 
The 
future 
trend 
of 
multiple 


processor microcomputer 
systems will be to simplify the 


software 
tasks 
of 
implementing 
communications, 
syn- 


chronization, 
and 
mutual 
exclusion. 
These 
functions 


could be performed 
in varying 
degrees 
by 
additional 


hardware 
bus functions. 


Potential rewards for a multiple processor architecture 


include enhanced system throughput, 
improved real-time 


response, modular system expansion, 
and improved 
sys- 


tem 
reliability. 
These 
benefits 
will pressure 
the tech. 


nology of parallel processing to include microcomputers 
in an increasing number of computer applications. 
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Triple-bus architecture 
lets a 


single-board microcomputer's 
CPU operate at full speed 
while other system components 
share the main memory. 


The introduction 
of Intel's iSBC 80/30 marks 
the 


beginning 
of the third 
generation 
of single board 


computer architecture. 
Two features separate the new 
microcomputer 
from second-generation 
single-board 


/LCs. The major one is a triple-bus 
architecture 
that 


supports 
a dual-port 
memory. 
As a result, 
the on- 


board CPU does not tie up the main system bus (Intel's 
Multibus) 
when using the memory. Moreover, with 


two ports, 
the memory 
becomes a global resource, 


accessible via the three buses from the on-board 8085A 
CPU as well as from remote CPUs and other external 
devices in multi master 
schemes. 
In additiol), the 80/30 contains two microprocessors: 
an 8085A acting as the master CPU and an 8041 single- 
chip microprocessor 
acting as a slave, or intelligent- 


110, processor. 


Jim Johnson, 
Project 
Leader, Craig 
Kinnie, 
Project 
Man- 
ager, 
and Mike Maerz, Marketing 
Manager, 
Intel 
Corp., 


Santa 
Clara, 
CA 95051. 


To appreciate 
the benefits of the 80/30's triple-bus, 


dual-port memory architecture, 
examine the following 


problem. Now that fully one fourth (l6-kbytes) 
of the 


available memory space in a 64-kbyte /LC system can 
reside on a single-board 
/LC, the CPU must share these 


16-kbytes 
with 
other 
system 
components, 
such as 


direct-memory-access 
devices, discs and other proces- 


sors. What's 
the best solution-especially 
when, in 


many applications, 
16-kbytes is all the memory that's 


required 
by the whole system? 


Alternatives 
have problems 


The 
most 
straightforward 
way 
is 
a 
split-buB 


architecture, 
in which both the CPU and the system 


have equal access to the memory (Fig. la). While the 
system 
bus will be able to handle 
memory 
access 


efficiently 
from devices tied to it, it will be tied up 


by the CPU-so 
external 
operations 
not related 
to 


memory 
accesses will be hindered. 
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1. Microcomputer-bus 
organizations 
takes several forms: 


In a split-bus 
approach 
(a) the CPU and system have equal 
access to memory, 
but the CPU ties up the system 
bus: 
in a single-bus 
(b), the CPU encounters 
extra 
delays 
in 


A single-bus 
approach 
(I:ig. Ib) is hampered 
by 
buffer 
and bus-intervention 
delays which limit the 


CPU's performance. 
And dual-bus architecture 
(Fig. 
Ie), while granting the CPU exclusive access, does not 
allow other bus masters 
access to the memory. Also 
dual-bus 
suffers 
from buffer delays. 


A triple-bus, 
dual-port 
architecture 
(Fig. Id) pro- 


vides the benefit of both single and dual-bus architec- 
tures: total system access and exclusive access by the 
CPU. But it also has its disadvantages: 
Dual-port 


architecture 
requires many buffers as well as access- 
arbitration 
logic. However, 
20-pin octal buffers 
in- 


troduced 
by several 
manufacturers 
don't 
take 
up 
nearly 
as much 
board 
space 
or cost as much 
as 


equivalent 
standard 
buffers. 
Since the octal buffers 


come in unidirectional 
or bidirectional forms-and 
at 


nearly 
the same cost-the 
three-bus 
approach 
used 


on the 80/30 actually 
takes only as many packages 


as the split-bus 
approach. 


Access arbitration 
is solved in the 80/30 with cycle 


status signals from the 8085A CPU. Instead of provid- 
ing equal access to the RAM from ooth the CPU and 
the system, the arbitration 
logic is designed to favor 


the CPU, By assigning the default state of the arbiter 


using 
the system 
bus. A dual-bus 
structure 
(c) also has 
buffer 
delays, and no system access to on-board 
memory. 
But a triple-bus 
(d) avoids 
all these 
problems, 
allowing 


total 
system 
access 
to memory. 


to the CPU, the logic anticipates aCPU memory access 
and reserves the memory until the cycle is complete. 


In addition, if an on-board CPU access is imminent, 


a reservation 
signal 
derived 
from the 8085A CPU 


status 
signals, 
the ALE (address 
latch enable), the 


address, 
and the cycle status 
signals (SO, SI, IOlM) 
will hold off bus contention. 
As a result, the CPU can 
operate at full speed without tying up the system bus. 


Of course, this extra CPU performance 
cuts into the 
rest of the system's 
memory-access 
time. However, 


the penalty 
imposed by the arbiter 
is less than 200 
ns-less 
than the time it would take a DMA device 
to regain control of the bus in the split-bus approach, 
where access must be interleaved. 


A bus hierarchy 


The three buses in the 80/30 hierarchy 
(Fig. 2) are 


an on-board bus, a dual-port 
(DP) bus and the Multi- 
bus (system 
bus). Innermost 
is the on-board 
bus, 


which connects the 8085A, all on-board I/O peripher- 
als and ROM. The next bus in the hierarchy, 
the dual- 


port 
connects 
a dual-port 
controller, 
I6-kbytes 
of 
dynamic 
RAM and a dynamic 
RAM controller. 
The 


RS232C 


COMPATIBLE 


DEVICE 


2. The full 80/30 one·board microcomputer is organized 
around 
its 
three 
buses: 
on 
board, 
dual-port, 
and 
the 


external-system 
Multibus. 
The main CPU. an 8085A, 
runs 


i$BC 201 


DISKETTE 


CONTROLLER 


RAM 


ADDRESSES 


48K-64K 


3. The microcomputer's on·board memory may 
be ad- 
dressed 
independently 
by the on-board 
central 
processor 
and 
Multibus 
bus 
masters 
to 
increase 
the 
efficiency 
of 
usage 
of the 
total 
available 
memory 
space. 


USER 
OESIGNA 
TED 


PERIPHERALS 


42 PROGRAMMABLE 


pARALLEL 
1/0 LINES 


at 
2.76 
MHz, while 
an 8041A 
one-chip 
microprocessor 


serves 
as 
a 
peripheral 
controller 
or 
slave 
processor, 


running 
with 
a 2.6-ms 
cycle 
time. 


outermost 
bus, the Multibus, 
offers 
modules 
that 


permit 
either 
the expansion 
or addition 
of system 


resources. 


With the on-board bus, the 8085A communicates 


with its on-board I/O and ROM (or PROM, if desirable) 
and the dual-port bus. Since the on-board bus permits 
access to the I/O and ROM only from the 8085A, all 
I/O and ROM (up to 8-kbytes are the 8085A's private 
property). 
And as a result, the 80/30 can operate on 


its on-board bus while another Multibus master uses 
the Multibus, 
accessing data from the board's dual- 


port RAM without 
reducing 
processor 
speed. 


The dual-port (DP) bus contains 16-k of read/write 


memory, 
implemented 
with 
Intel's 
2117 16-kbyte 


dynamic RAM and the 8202 dynamic RAM controller 
(DRC). The DRC interfaces 
the DP bus to the 16- 


kbytes 
of dynamic 
RAM, and provides 
an almost 


static-RAM type interface. It provides the system with 
multiplexed 
addresses, 
address 
strobes, 
and refresh 


control to the RAM, as well as refresh/access 
arbi- 


tration 
and acknowledges. 
The RAM on this bus can be accessed from either 
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the 8085A on the 80/30 or the Multibus. 
The DP 
controller arbitrates 
the RAM requests and performs 
the bus exchanges. 


The DP controller always leaves the DP bus under 
the control of the 8085A when it is not in use. This 
permits 
the 8085A to operate at maximum processor 
speed when controlling 
the bus, since there isn't any 
bus-exchange 
overhead. When the Multibus requests 
access to the DP RAM, the DP controller 
transfers 
control of the DP bus to the multibus, 
as soon as the 
DP bus is not busy. Once the Multibus 
transfer 
is 
complete, 
the DP bus is returned 
to the 8085A. 


Multiple 
communication 


The DP controller 
has two independent 
address 
decoders-one 
for decoding Multibus 
requests, 
the 
other for 80/30 requests. 
This not only permits 
the 
address 
space of the memory 
to be located in two 
different 
parts of memory (Fig. 3), it enables several 


80/30s to talk to each other over the Multibus, while 
sharing 
the same on-board 
address 
as seen by the 


8085A. Thus, one program can be loaded in any 80/30 
without 
relinking 
and relocating 
the software 
for 


execution. 


Each bus can communicate 
either within itself, or 


with the adjacent bus. Thus, the on-board bus cannot 
communicate 
directly 
with the multibus. 
However, 


when the CPU makes a bus request, the on-board and 
dual-port buses simultaneously 
determine 
if they can 
fulfill it. If the on-board 
bus can acknowledge 
the 
request, 
it does so, and the DP bus control 
is not 
required to determine 
if the DP bus can acknowledge 


the request. 
If the DP bus, not the on-board, 
can 
acknowledge the request, it does so, and the controller 
then lets the CPU use the bus. Thereafter, 
the RAM 


controller 
completes the operation 
and generates 
an 
acknowledge 
signal. 


If neither the on-board nor DP bus can fill the bill, 


the Multibus is solicited by the CPU. Since a bus can 
only communicate 
with an adjacent bus, the on-board 
bus must request 
the DP bus to communicate 
with 
the Multibus via the DP controller. The on-board bus 
will retake control of the DP bus only after the request 
to use the Multibus is granted. 
This prevents lockout 
problems with the DP bus, where the CPU requests 
the Multibus 
when it is controlled 
by another 
bus 
master 
accessing the DP RAM. 


How the 80/30 performs 
is directly related to how 
many 
buses 
it must 
use to complete 
a requested 
operation. The on-board bus always operates at max- 
imum processor speed. The DP bus operates at max- 
imum only if it hasn't been busy and a memory refresh 
cycle was not in process. The processor speed when 
the Multibus is used depends on bus overhead involved 
and the type of module requested. 
The 80/30 boasts more than a three-bus 
architec- 
ture. For one thing, its I/O is designed to interface 
to 
a wide 
variety 
of external 
devices, 
including 
switches, 
motor 
drives, 
bistable 
sensors, 
displays, 


The iSBC 80/30 uses the latest 
LSI components 
to 


obtain 
the highest 
performance 
of any Intel 
single- 


board 
computer. 
Built 
on a 6.75 
X 12-in. board, 
it 


contains 
the following 
features: 


• 8085A central 
processor 
operating 
at 2.76 MHz. 


• 16-kbytes of dual-port 
RAM using Intel's new 16- 


kbyte dynamic 
RAMs and 8202 dynamic 
RAM con- 
troller. 
• Sock~ts for 2, 4 or 8-kbytes of ROM using Intel's 


2758, 
2708, 
2716, or 
2332 EPROMs 
or 
ROM 
re- 
placements. 


• A socket 
for Intel's 
8041A/8741A 
universal 
pe- 


ripheral 
interface 
(UPI) 
having 
18 software-con- 


figurable 
I/O 
lines with sockets 
for drivers/termi- 


nators. 


• A programmable 
serial-communication 
channel 
with RS-232 interface 
and programmable 
baud rate. 


• Multibus 
control 
logic which 
allows 
up to 16 
masters 
to share 
the system 
bus. 


• 12 vectored 
priority 
interrupts. 


• Two programmable 
16-bit BCD or binary internal 
timers. 


keyboards, 
printers, 
teletypewriters, 
communicator 


modems, 
cassettes 
and other 
computers. 
This ver- 
satility 
is provided with LSI programmable 
devices 


such as Intel's 8255 programmable 
parallel I/O device, 


8251A programmable 
communication 
channel, 
8253 


interval 
timer, 
8259 
interrupt 
controller, 
and 


8041A/8741A universal 
peripheral 
interface 
(UPI). 


The slave processor 


The ability to interface this wide variety of external 
devices is facilitated 
by the 8041A/8741A UPI (Fig. 


4), which can be added to the 80/30. The UPI is a 
complete single-chip microcomputer 
which acts as a 


peripheral 
to the 8085A. It is completely 
user-pro- 


grammable 
with l-kbyte of ROM (8041A) or EPROM 


(8741A) memory for data storage. The UPI allows you 
to fully specify your control algorithm in the peripher- 
al chip without 
relying on the 8085A. Devices such 


as printer 
controllers 
and keyboard scanners 
can be 


completely self-contained, 
relying on the 8085A only 


for data transfers. 
The UPI is a powerful8-bit 
CPU with a 2.6-ms cycle 


time and an instruction 
set optimized for bit manipu- 


4. 
The 8041A/8741A 
single-chip 
microcomputer 
(UPI-41) 
has 
its 
own 
on-chip 
ROM and 
RAM and 
can 
be 
pro- 
grammed 
to perform 
various 
peripheral 
control 
functions. 


5. The UPI's two data registers 
are organized 
so that the 


8085A 
CPU can write 
in just 
one register 
and read from 
the 
other. 
As a result, 
the 
two 
registers 
appear 
as one 
register 
to the 
main 
8085A 
CPU. 


lation 
and 
I/O 
operations. 
It 
contains 
an 
8-bit 


counter/timer, 
buffers 
to 
communicate 
with 
the 


8085A, and two 8-bit programmable 
I/O ports, which 
can be customized 
by software 
or by plugging 
in 


suitable line drivers or terminators 
into sockets. The 


UPI also has two input bits that it can test directly. 
An RS-232 driver and receiver on the 80/30 permit 
the UPI to be programmed 
as a simple serial-com- 


munication 
channel. 


Interfacing 
to the on-board 
bus 


The UPI interfaces 
asynchronously 
with the on- 


board bus using two data and two status 
registers. 


The UPI's two internal 
data registers 
appear to the 


8085A as only one register, since one data register can 
be written 
into only by the UPI and read only by the 


8085A, and the other can be written 
into only by the 


8085A and read by the UPI (Fig. 5). This is done to 
prevent 
the two CPUs from simultaneously 
writing 


into a data register. 


The 
UPI 
can communicate 
with 
the 
8085A by 


loading 
a data 
register 
and then 
returning 
to its 


previous control task. The 8085A can periodically poll 
the UPI status port for the valid-read (VR) flag, which 
is set in hardware 
when the 'UPI writes to its data 


port,.or the UPI can generate an interrupt 
to the 8085A 


via an I/O bit that can be programmed 
to be the VR 


flag. 
Once the 8085A determines 
the VR flag is true, it 


can transfer 
the data 
to its own memory 
without 


disturbing 
the UPI. The VR flag is automatically 


cleared after the data are transferred. 
Similarly, when 


the 8085A transfers 
data to the UPI, a valid output 


(VO) flag 
is set 
and 
an interrupt 
to the 
UPI 
is 


generated 
(if enabled) automatically. 
Once the UPI 


transfers 
the data, the VO flag is cleared. The VO flag 


can also be programmed 
to a port bit for generating 


interrupts 
to the 8085A to indicate that the transfer 


is complete. 


An extensive 
interrupt 
system 


The 80/30 provides 12 vectored priority interrupts, 


four of which are handled 
directly 
by the 8085A's 


interrupt-processing 
capability 
and routed 
to fixed, 


unique memory locations. The remaining 
eight levels 


are handled via the 8259A programmable 
interrupt 


controller 
(PIC), which generates 
a unique memory 


address 
for each level. These addresses 
are equally 


spaced at intervals 
of four or eight (software-selec- 


table) bytes. This 32 or 64-byte block may be located 
to begin at any 32 or 64-byte boundary 
in the 65,536- 


byte memory space. A single 8085A jump instruction 
at each of these addresses 
then provides the linkage 


to locate each interrupt-service 
routine independently 


anywhere 
in memory. The PIC provides a selection 


of four priority 
algorithms 
so that 
the manner 
in 


which real-time 
requests 
are processed may be con- 


figured to meet the requirements 
of the system under 


design. 


The 80/30 also has two 8253-based programmable 


16-bit BCD and binary timers/event 
counters, which 


can be used for a variety 
of functions. 
Both timers 


may be set to act as a rate generator 
(divide-by-N 


counter), 
a square-wave 
generator, 
a programmable 


retriggerable 
one-shot, 
or one of the timers 
can be 


jumper-selected 
as an event counter. In addition, 
an 


interrupt 
can be generated 
when a time interval 
has 


expired or when a specified number 
of events has 


occurred. 
To see how useful 
the 80/30 can be, consider 
a 


supervisory 
control/monitoring 
system (Fig. 6) using 


an Intel iSBC 80/30 single-board computer, 
iSBC 201 


diskette controller, and iSBC 732 analog input/output 
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SYNCHRONOUS 
DATA 


LINK 


DIGITAL 


CONTROL 


INPUTS 


ANALOG 


CONTROL 


SIGNALS 


ANALOG 


PROCESS 


VARIABLES 


6. 
In this application 
example, 
the 80/30 forms 
the heart 


of a remote data-acquisition 
system. By taking 
advantage 


of the one-board 
microcomputer's 
dual-port 
memory 
and 


universal 
peripheral 
interface. 
the 
system 
achieves 
a 


combination 
of attractive 
cost and efficiency. 


board. Here local commands 
and process-status 
sig- 
nals are given and displayed 
on a CRT, which is 


interfaced 
via 
the 
iSBC SO/30 resident 
UPI and 


RS232C components. Process variables are converted 
from analog to digital 
using the analog I/O board. 


Control variables 
are passed over the Multibus from 


the SO/30 to the 732, where they are converted from 
digital 
to analog. 
System data are logged on two diskettes, 
which are 


controlled by the 201. The controller board's on-board 
DMA interface accesses the SO/30's dual-port memory 
and stores 
the data on one of the floppy discs. 


At the end of the day, a remote 
host processor, 


interfaced 
to the SO/30 via a modem (through 
the. 


SO/30's S251A and RC232C circuits) 
can request 
all 
or part of the diskette-resident 
data. Here, the SO/30 


uses its on-board dual-port 
memory as a data buffer 


for transfers 
to the host. 


Intel's RMX/SO real time executive, disc-file system 
and 
analog 
drivers 
provide 
the 
majority 
of the 


system's 
software .•• 


Note: Multibus 
and iSBC are registered 
trademarks 


of Intel 
Corp. 


Technical articles ----------- 


16-bit single-board computer 
maintains 8-bit family ties 


Three-bus 808B-based board addresses a megabyte, 
communicates over expanded system bus 


o For the first time ever, 8- and 16-bit single-board 
computers can brainstorm over the same system bus. 
The iSBC 86/12 16-bit SBChas been designed to work 
intimately with its predecessors, the iSBC 80 family of 
8-bit boards. What's in it for the user? Design flexibili- 
ty-8-bit 
designs can be enhanced to 16 bits, developed 


software can be transported and, beyond that, 8- and 
16-bit devices can be mixed in multiprocessing configu- 
rations. Several features make these options possible: a 
16-bit CPUand instruction set designed for 8-bit compat- 
ibility; greatly 
expanded memory resources; and an 


extension of the Multibus specifications. 


At the heart of the iSBC 86/12 is a 16-bit, high- 
performance 
metal-oxide-semiconductor 
8086 central 
processing unit that operates at 5 megahertz. Because 
the 8086 instruction set is a superset to that of both the 
8080A and 8085A 8-bit processors, the CPUcan execute 
the full set of 8080A/8085A-type 8-bit instructions plus 


a new set of 16-bit instructions. Thus, programs gener- 
ated for 8-bit-cPu systems can easily be upgraded to run 
on the iSBC 86/12 using the software tools available 
with the Intellec microcomputer development system. 
Programs 
written 
in Intel's 
high-level programming 
language, PLlM,can be executed on both iSBC 80 and 
iSBC 86 products, preserving the software investment in 
8-bit systems as a user moves into 16-bit applications. 


Other features of the 8086 CPU are signed 8- and 
16-bit arithmetic (including multiply and divide), effi- 
cient interruptible byte-string operations, and improved 
bit manipulation. Furthermore, the 8086 provides mech- 
anisms for reentrant 
code, position-independent 
code, 


and dynamically relocatable programs. 


This enhanced processing power is supported by the 
largest memory ever offered on a CPU board (Fig. I). 
Memory address space has been extended over the iSBC 
80 series to one million bytes. Up to 16 kilobytes of 
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2. LSI+SBC=18/12. 
A number of programmable 
LSI devices take credit for the power and flexibility of the iSse 86/12. 
Note their 
interconnection to the three-bus hierarchy. When the 8086 requests a resource. the system bus is used only as a last resort. 


read-only memory can be installed on the iSBC 86/12 
itself. 
Furthermore, 
an 
additional 
32 kilobytes 
of 


dynamic random-access memory with on-board refresh 
may be accessed independently by the CPU or by the 
system bus (Multibus). 


Like the iSBC 80/30, the 86/12's 
RAM has dual ports 


to extend its use off board for access by other Multibus 
masters, including single-board computers, direct-memo- 
ry-access devices, and peripheral controllers [Electronics, 
Aug. 17, p. 109]. All memory operations on the board 
occur independently of the Multibus, freeing it for exter- 
nal parallel operations. 
For applications that require 


data integrity at all times, a separate bus supplies power 
to the RAM and support logic via the edge connector. An 
auxiliary power source energizes the RAM in the event of 
power failure. 


Multibus-the 
new look 


To exploit the greater performance of the 8086 CPU 
and simultaneously make the iSBC 86/12 fully compati- 
ble with the iSBC 80 family of 
SBCS and expansion 


products, the Multibus specification has been extended 
to support 20 bits of address and 16 bits of data. The 
control lines, too, have been expanded to direct 8- and 
16-bit data transfer over the system bus. These improve- 
ments enable the iSBC 86/12 to address directly a full 
one megabyte of system memory, access data in 8- or 
l6-bit word lengths, and recognize and acknowledge a 
variety of interrupts. 


Address space has been enlarged to 1 megabyte by 


adding four address lines, A,o-A13• Next, 8- and 16-bit 


data operations have been defined to permit both types 
in the same system. This is done by reorganizing the 
memory modules, adding one new signal and redefining 
another. The memory is divided into two 8-bit data 
banks, which form a single 16-bit word. The banks are 
organized such that all even-byte-addressed data is in 
one bank (00-0,) and all odd-byte-addressed data is in 
the other bank (D,-DF). 
A new bus-address signal has 


been defined to control the odd-byte bank called byte 
high enable 
(BHEN) 
during 
16-bit operations. 
When 


active, BHEN enables the high byte of the data word from 
the addressed boards on the D,-DF Multibus data lines. 
Ao controls the even byte bank and, when inactive, 
enables the low byte of the data word o.n the 00-0, 
Multibus data lines. All word operations must occur on 
an even-byte-address boundary with 
BHEN 
active for 


maximum 
efficiency. 
(Ao is inactive 
for 
all 
even 


addresses-see 
the table.) Word operations on odd-byte 


boundaries will be converted to 2-byte operations by the 
8086, one for low-byte, one for high-byte. Byte opera- 
tions can occur in one of two ways. The even bank is 
accessed when BHEN and Ao are both low. This puts the 
data on 00-0,. To access the odd bank (normally placed 
on D,-DF during a word operation), a new data path has 
been defined. The active state of Ao and the inactive 
state of BHEN are used to enable a swap-byte buffer, 
which places the odd data bank on 00-0,. This permits 
an 8-bit master access to both bytes of the data word 
while controlling only Ao. Ao therefore specifies a unique 
byte and is not part of the word address, since all word 
operations are on even-byte boundaries. 


The iSSC 86/12 owes much of its flexibility to program- 
mable large-scale integrated devices. An 8255A peripher- 
al interface chip provides 24 programmable I/O lines that 
may be tailored to the customer's 
needs by simply 


programming the device for input, output, or bidirectional 
modes with or without handshaking abilities. In conjunc- 
tion with the 8255A's configuration the user may then 
select appropriate line drivers and terminators for the I/O 
lines that can be inserted into sockets on the iSSC 86/12 
board. 
An 8251A universalsynchronous/asynchronous receiv- 


er/transmiller 
is included to provide an RS-232-C inter- 


face for serial communication with other computers, RS- 
232-C-type peripherais (casselle tape, modems, etc.) or 
cathode-ray-tube terminals. The 8251A enables the user 
to customize the communication link. Synchronous/asyn- 


chronous mode, data format, control character format, 
parity and baud rates from 75 to 38.4 kilobauds are all 
under program control. 


For system timing functions an 8253 programmable 


interval timer provides two programmable timers, each of 
which may be used as a square-wave generator, retrigger- 
able one-shot multivibrator or as an event counter. 


The interrupt structure of the iSSC 86/12 encompasses 
nine levels with vectored priority. Eight of these levels are 
handled by an 8259A programmable interrupt controller 
Chip, which 
may be configured for 
different 
priority 


processing modes in accordance with the application. 
One nonmaskable interrupt is available to immediately 
alert the CPU to catastrophes like a power failure, in which 
case the CPU·can branch to an appropriate routine in 
memory to effect an orderly system shut-down. 


JUMPER- 


SELECTABLE 
SYSTEM 
12B'KllOBYTE 


SEGMENT 


(X PARflMETER) 


AOOOO - 
BFFFF 


BOOOO- 
9FHF 


60000 
- 
7FFFF 


40000 
- 
5FFFF 


SWITCH- 
SELECTABLE 
ADDRESS 
DISPLACEMENT 
(Y PARAMETER) 


17FFF 


lBFFF 


lDFFF 


3. RAM, pl••••. 
The 808S's 
view 
of on-board 
memory 
is fixed 
from 
zero 
to 07FFFH. 
When 
an outside 
master 
accesses 
this space, 
the 
DP 


controller 
performs 
the translation. 
Here, 
locations 
OSOOOH to 07FFFH 
are available 
to another 
master 
by addressing 
CAOOOH to CBFFFH. 


Since all 8-bit accessesvia Multibus 
are done on the 


lower byte of the data word, the iSBC 86/12 can access 
8-bit memory or 110 devices from the system bus. This 
makes the iSBC 
86/12 
compatible 
with 
all 
iSBC 
80 


Multibus 
modules. 


More interrupts, 
too 


The iSBC 86/12 expands the previous Multibus 
defi- 


nition of interrupts 
by creating two distinct 
types: non- 


bus-vectored 
(NBVI) 
and bus-vectored 
(BVI) 
interrupts. 


Each Multibus 
interrupt 
line can be individually 
defined 


through 
software to be a BVI or 
NVBJ. 
Using 
BVIS, 
the 
interrupt 
capability 
of 
a 
Multibus 
system 
can 
be 
increased to 64 bus-vectored-priority 
interrupts. 


Using NBVIS, 
a slave module activates an interrupt 
line 
and the interrupted 
bus master generates its own restart 
address to service that interrupt. 
The Multibus 
address 


or data 
lines are not used. A 
BVI 
uses the Multibus 


address and data lines to communicate 
with 
the inter- 


rupting slave. When the slave module generates an inter- 
rupt, the bus master requires that module to generate the 
restart 
address. 
One 
additional 
command 
signal 
is 


4. Open loop. Shown above is a simple alarm and monitoring system. The iSBC 711 analog-input board samples 16 differential inputs and the 
8-pit iSSG 80/20 compares the inputs to the high and low limits. An alarm condition iIIufTlinatesan LED and gets logged'on a teletypewriter. 


5. ClosecIloop. 
Suppose the system in Fig. 4 needs to be upgraded to handle a closed-loop system. For this application an iSSG 86/12 
replaces the 80/20-04 
to cope with the higher processing. The output controi variables are handled by an iSSG 724 analog-output board. 


I. Multi/maater. To enhance the control system in Fig. 5, add a dedicated GPU to control valves, vents, and dampers that, in turn, affect 
pressure and flow parameters in the syslem. This has been done by adding an iSSG80/05 
in a Multibus/multimaster 
arrangement. 


defined-interrupt 
acknowledge 
(INTA)-to 
request 
the 


restart 
address 
from the slave module. 


The iSBC 
86/12 
board 
architecture, 
like that 
of the 


8-bit iSBC 80/30, 
is organized 
around 
a three-bus 
hier- 


archy: an on-board 
bus, a dual-port 
bus and a system bus 


(Multibus). 
All 
three 
buses 
have 
been 
expanded 
over 


their 
80/30 
counterparts 
to incorporate 
20 address 
lines 


and 16 data lines. 


The iSBC 86/12 architecture 


The on-board 
bus links the 8086, all the. I/O peripher- 


als, and the read-only 
memory. 
Next 
in the hierarchy 
is 


the dual-port 
bus, which connects 
to the DP controller, 
32 


kilobytes 
of 
dynamic 
RAM, and 
the 
dynamic 
RAM 


controller. 
Finally, 
the system 
bus permits 
expansion 
of 


system resources 
through 
Multibus 
modules 
(Fig. 2). 
The bus protocol 
of the iSBC 86/12 
dictates 
that each 


of the three 
buses communicate 
with an adjacent 
bus or 


operate 
independently. 
When 
the 
CPU makes 
a request 


for a resource, 
the on-board 
and dual-port 
buses simulta- 


neously 
determine 
if 
their 
hardware 
can 
fulfill 
the 


request. 
If the on-board 
bus is able to acknowledge 
the 


request, 
it does so and the 
DP bus is not disturbed. 
(The 


DP 
bus 
is not interrupted 
to determine 
whether 
it can 
acknowledge 
the request.) 
The 8086 always 
controls 
the 


on-board 
bus, 
and 
requested 
operations 
can 
be 


completed 
without 
delay. 
If the 
DP bus is needed, 
it is 


requested 
and the dual-port 
controller 
grants 
the use of 


the bus to the processor. 
Thereafter, 
the dynamiC-RAM 
controller 
completes 
the 
operation 
and 
generates 
an 


acknowledge. 


If neither 
the on-board 
nor the 
DP bus can satisfy 
the 


request, 
the 
CPU asks for the system bus. The 8086 must 


use the 
on-board 
and 
dual-port 
buses 
to communicate 
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} TO OTHER ClOSEO'lOOP 
SYSTEMS 


7. Four 1001'8. An iSBC 86/12 
can be used in conjunction with an iSBC 544 intelligent communications controller to perform a supervisory 
function for four closed-loop systems. The iSBC 544 controls the line protocol and the iSBC 86/ 12 processes the 544's data. 


with the system 
bus. The 
8086 
takes 
control 
of the 
OP 
bus when the system 
bus is granted. 
This prevents 
lock- 


out problems 
with the 
OP bus-that 
is, when the proces- 


sor requests 
the system bus while another 
bus master 
has 


control 
of it and is accessing 
the dual-port 
RAM. 
Naturally, 
the 
fewer 
the 
buses 
it has to access, 
the 


faster 
the 
iSBC 
86/ I2 completes 
a transaction. 
The 


on-board 
bus always 
operates 
at maximum 
board 
speed. 
But the OP bus operates 
at maximum 
board speed only if 


it was not busy or taken up with a memory 
refresh 
cycle. 
When 
the system 
bus is brought 
into play, the processor 


speed 
depends 
on the overhead 
in acquiring 
it and 
the 


type of Multibus 
module 
being accessed. 


With 
this three-bus 
architecture 
the iSBC 
86/12 
can 


be operating 
over its on-board 
bus at the same 
time as 


another 
Multibus 
master 
is using the system 
bus. It does 


so by accessing 
data from the 
OP RAM 
at no reduction 
in 
board speed. The on-board 
bus permits 
access only from 


the 8086. Thus all 110 and 
!loOM are private 
to the 8086. 


The dual-port 
controller 
has two independent 
address 
decoders-one 
for the 8086 
and 
one for the 
Multibus. 
The 8086 decoder 
fixes the 8086's 
RAM 
addresses 
from 


hexidecimal 
00000 
to 
07FFF 
using 
a 
fusible-link 


programmable 
ROM. 
The 
Multibus 
decoder 
allows 
the 
user to select any address 
range for the on-board 
RAM 
by 


specifying 
two 
parameters-a 
top-of-memory 
pointer 


and the size of the accessible 
memory. 
The 
TOM 
pointer 


(as seen by another 
Multibus 
master) 
can be set to any 


8-kilobyte 
boundary 
in the 
I-megabyte 
memory 
space. 


The amount 
of memory 
on the iSBC 86/12 
accessible 
by 


another 
master 
can be set to 8,16,24, 
or 32 kilobytes 
(or 
no access) 
with an on-board 
jumper. 
For example, 
fixing 


the accessible 
memory 
size to 24 kilobytes 
provides 
the 


8086 
with 
8 kilobytes 
of 
RAM 
that 
only 
it can 
access. 


This private 
area 
can be used for the processor's 
stack, 
interrupt 
jump 
table 
and other 
special 
system 
paramet- 


ers 
that 
are 
generally 
protected 
from 
other 
Multibus 
masters. 
The 
only 
addressing 
restriction 
is 
that 
the 
memory 
block accessible 
to the Multibus 
cannot 
cross a 


I28-kilobyte 
boundary. 
Suppose 
a M ultibus 
master 
wants 
to load a program 


into 
the 
iSBC 
86/12's 
dual-port 
RAM 
for 
execution. 
Since 
the 
8086's 
view of the 
OP-RAM 
address 
space 
is 


fixed, the Multibus 
address 
must 
be translated 
into the 


on-board 
8086 
memory 
space. 
The 
OP 
controller 


performs 
this 
translation 
by mapping 
the 
TOM 
pointer 


(as 
seen 
by other 
Multibus 
masters) 
to 8086-address 


07FFFH, 
the 
top of the 
8086's 
on-board 
RAM. 
Point- 


er - I is mapped 
to the top of 8086 on-board 
RAM 
- 
I, 


and so on. 


In the example 
shown in Fig. 3, the Multibus 
address 


selection 
is divided 
into three 
parts-two 
selecting 
the 


TOM 
pointer 
(X and Y) and one selecting 
the size of the 


accessible 
memory 
(Z). 
The 
TOM 
pointer 
is equal 
to a 


128-kilobyte 
segment 
(X) plus address 
displacement 
(Y) 


from that segment. 
In this example, 
X is set to COOOOH 


and 
Y is set 
to OBFFFH, 
so the 
TOM 
pointer 
equals 


CBFFFH. 
Next, the size of the accessible 
memory 
(Z) is 


set, in this case to 8 kilobytes. 
This address 
translation 


makes 
the top 8 kilobytes 
of the 8086's 
RAM 
locations 


06000H 
to 
07FFFH 
available 
to 
another 
Multibus 


master 
when 
it 
addresses 
locations 
CAOOOH 
to 


CBFFFH. 
The 
8086 still has 24 kilobytes 
(OOOOOH to 


05FFFH) 
of private 
memory. 


Multiprocessing 
schemes 


In multiprocessing 
systems, 
a master 
must 
be able to 


access 
the system 
without 
another 
master 
obtaining 
the 


bus. The iSBC 
86/12 
incorporates 
bus-arbitration 
logic 


to effect these transactions. 
Since the system 
bus is only 


requested 
when a system 
resource 
is needed, 
the 
iSBC 


86/12 
can 
perform 
true 
parallel 
processing 
with 
other 


iSBC 80 or 86 masters. 


A typical 
example 
is the 
use of a common 
memory 


location 
that contains 
the status 
byte (busy/not 
busy) of 


a floppy-disk 
controller. 
When 
the floppy disk is needed, 


the master 
must first read the location 
and, 
if not busy, 


write the status 
word without 
another 
master 
obtaining 


the bus (to use the floppy disk). 
A bus-lock 
function 
on 


the 
iSBC 
86, 
once 
enabled, 
allows 
the 
iSBC 
86 
to 


maintain 
control 
of the 
system 
bus 
until 
the 
lock 
is 


disabled 
by program 
control. 
This bus-lock 
function 
may 
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be activated in one of two ways-by 
an output bit from 
the resident 8255A peripheral-interface 
chip or by a 
software prefix on any 8086 instruction. The iSBC 86 
can perform the test and set function by exchanging the 
accumulator with the memory location, preceding the 
instruction by a lock prefix. For example, the status 
word is read into the accumulator and, without another 
intervening bus cycle, a busy status is written. The 
accumulator is then tested: if busy-try 
again (writing a 
busy does not destroy status as it was already busy); if 
not busy, the floppy disk is now under the master's 
control and the status location is set to busy. 


The iSBC 88/12:. 
design tool 


For system debugging and full-speed execution, the 


iSBC 86/12 can be linked to the Intellec microcomputer 
development system. Programs generated on the Intellec 
system can be downloaded into the iSBC 86/12 
RAM via 
cables. Through a virtual-terminal capability, the Intel- 
lee console can directly access an iSBC-resident monitor, 
which provides commands for software debug. Once the 
debugging cycle is completed, the user has the option of 
uploading the software back to the Intellec for storage 
on diskettes. 


The Multibus and form-factor compatibility of the 
8-bit iSBC 80 and 16-bit iSBC 86 single-board comput- 
ers provide a degree of design flexibility previously unob- 
tainable. 
Initial design problems can be solved with 


low-cost 
8-bit 
hardware. 
As product 
requirements 
evolve, .l6-bit performance can be added. Eventually, 8- 
and 16-bit multiprocessor solutions can be conveniently 
implemented. 


Consider the application shown in Fig. 4, an alarm 


and monitoring system in a typical process plant. Sixteen 
differential inputs from pressure and flow transducers 
are sampled once every second, then compared to high 
and low limits previously entered through thumbwheel 


switches. The iSBC 711 analog-input board takes care of 
sampling the inputs and the 8-bit iSBC 80120-4 com- 
pares the data to the high and low limits. Whenever 
these limits are exceeded, an alarm LED lights up and the 
alarm condition is logged on the system teletypewriter 
along with input identification, high limit, low limit and 
sampled value. 


Closed loops 


Instead of an open-loop system, suppose the design 


must be enhanced to control four output variahles- 
thereby making it a closed-loop system. The sampling 
rate must be increased to once every third of a second 
and more processing will be required to run through the 
control algorithm and output the control-loop data. For 
this application, and iSBC 86/12 replaces the 80120-4 to 
handle the higher processing requirements. An iSBC 724 
analog-output board is also added to provide the four 
output-control 
variables 
(see Fig. 5). Carrying 
this 


example one step further, one may want to dedicate 
another processor to controlling valves, vents, and damp- 
ers that in turn affeet pressure and flow parameters in 
the system. This can be done by adding an iSBC 80/05 
in a multimaster arrangement as shown in Fig. 6. 


Finally, an iSBC 86/12 can be used with an iSBC 544 


intelligent communication-controller 
to supervise four 


closed-loop systems of the type shown in Fig. 6. The 
86/12 of each system interfaces with the supervisory 
system via its serial interfaces, which are connected to 
the iSBC 544's serial ports (see Fig. 7). The iSBC 544 
performs the control functions associated with the line 
protocol. The supervisory iSBC 86/12 can access the 
iSBC 544's dual-port memory and can perform further 
processing of the data received from the four closed-loop 
systems. In this configuration large amounts of memory 
may be required; since the iSBC 86/12 can address up to 
I m'egabyte, this presents no problem. 
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A new family of MULTIMODULETM boards 


extends the solutions provided by 


Intel's single board computers 


Figure 
1. The iSBX 350™ 
Programmable 
I/O MULTI MODULE 
plug·in, 


shown 
here, 
connects 
directly 
on one end into 
the special 
iSBX 
bus connector 
and screws 
onto 
the edge 
of the single 
board 
com· 
puter 
on the other 
end. 


A 


complete 
new 
tamily 
of 
product." 
called 


MULTIMODULE 
board." 
has been 
announced 


by 
Intel 
Corporation. 
The 
new 
MULTI- 


MODULE 
board., designed 
to extend 
the func- 


tional 
capabilities 
of .,ingle 
board 
computet<, 
at much 


lower 
cost 
than 
ha,> been 
pre,·iousl,. 
possible 
Intel 
i., 


'>upporting 
the 
MULTIMODULE 
concept 
with 
a new 


bus standard-the 
iSHX bu'>. The 
iSBX bus will no\\ 
be 


de~igned 
into 
a ncw 
generation 
of 'iingle 
board 
com- 


puters 
to achieve 
compalibliity 
with 
the emerging 
iSH X 


bus compatible 
MULTIMODULE 
product 
line. 
U.,ers ot 


Intel',> 
single 
board 
computers 
can 
incrementally 


expand 
system 
rc~ource" 
by adding 
.,mall 
12.1'5" x 3.7"1 


iSBX MULTIMODULE 
boards 
which 
plug directly 
into 


iSHC boards 
Three 
new 
iSBX bus MULTIMODULE 
plug-ins 
have 


been 
introduced-modules 
for parallel 
1/0, 
serial 
I/O, 


Figure 2. The iSBX 350™ Programmable 
1)0 MULTIMODULETM 
board provides 24 programmable 
1/0 lines using the 8255A·5 pro- 


grammable 
peripheral 
interface. 
Sockets are provided lor inter- 
changeable 
line drivers/lerminators. 


Figure 3. The iSBX 351™ Serial I/O MULTIMODULE board extends 
the serial communications 
capability 
01 a single board computer 


via an Intel' 
8251A USART. It includes 
an on·board programmable 


baud rate generator, two programmable 
16-bit BCD/binary 
timers, 
and RS232C or RS422/449 interlacing. 


Figure 4. The iSBX 332™ Floating 
POint Math MULTIMODULE 


board uses an Intel- 8232 Floating 
Point Processor and is com· 


patible with the new proposed 
IEEE formal. It provides users with 


both single-precision 
(32-bit) and double·precision 
(64·bit) 
arithmetic 
lunctions. 


and floating-point math. The showcase for the MULTI- 
MODULE family is the iSBC 80/1013 board-the 
first 


iSBX bus compatible single board computer. 


MULTIMODULETM boards 
allow 
users to 


tailor 
board level products 


Customers 
can choose MULTIMODULE 
boards to 


precisely configure single board computers 
for their in- 


dividual applications at a lower cost. The MULTIMOD- 
ULE boards enable users to buy exactly the capabilities 
that they require for their iSBC-based 
systems. 
This 


can, of course, keep system size and system cost at a 
minimum. 


Any of the three new iSBX bus MULTlMODULE 


products-the 
iSBX 350 Programmable 
I/O, 
the iSBX 


351 Serial 1/0, and the iSBX 332 Floating Point Math 
board-plug 
into a special interface called the iSBX bus 


on the iSBC 8011013single board computer, 
(see Figure 


11.The iSBXbus is being introduced by Intel to facilitate 
the interface 
betweeen 
the iSBX MULTIMODULE 


boards 
and the 
iSBC products. 
The 
iSBX bus will 


become a standard, similar to the standard MULTIBUS 
system architecture. 
The new iSBX bus allows system 


expansion 
through 
the new MULTIMODULE 
boards 


without making any demands on the system's MULTI- 
BUS interface. As a result, the system design achieves 
maximum 
on-board performance 
while freeing up the 


MULTIBUS interface for other system activities. 


The new iSBC 80/ lOB single board computer is fully 


compatible 
with the popular 
iSBC 80110A, but it is 


customer-expandable 
in "all directions~' This board can 


be expanded 
in three dimensions 
to tailor 
EPROM, 


RAM, and I/O needs directly on the board. This gives a 
user a built-in 
adaptahlility 
on one board that 
was 


previousl y unattainable. 
First, the user can choose four 


types of Intel PROMs-the 
2708, 2758, 2716 or 2732- 
expandable 
up to 16K bytes. 
Second, 
lK of RAM 


memory is included on-board and may now be extended 
up to 4K with the use of standard Intel 2114A-5 lK x 4 
static RAMs. Sockets on the 80/1013 board are provided 
for these additional 
RAMs. Input / output 
is the third 


dimension in every single board computer and may now 
be' expanded on-board the iSBC 80/1013 by using one of 
the iSBX bus MULTIMODULE 
boards. In addition, 
a 


l.()4 millisecond 
timer has been added as a standard 


feature of the iSBC 8011013 board. In comparison, 
the 


iSBC 80nOA board has only lK of on-board RAM, 8K of 
EPROM 
memory, 
no I/O 
or memory 
expansion 


facilities and no timer. 


Two of the new MULTIMODULE boards-the 
iSBX 
350 and iSBX 351-provide 
expansion 
to the II 0 


already on the iSBC 80/ lOB board. The iSBX 350 Pro- 
grammable 
I/O 
MULTIMODULE 
(see Figure 21 pro- 
vides 24 I/O lines with sockets for interchangeable 
line 


Here's what ISB)(TMbus MULTIMODULESTM 
provide the user: 


• The ability 
to Incrementally 
expand the iSBC Single 


Board Computer, via iSBX bus, allowing 
the user to 


add only the function 
his application 
requires. 


• The on-board addition 
of totally 
new capabilities 


(mathematics 
processing 
and the like) to single 


board computers. 


• Maximum 
performance 
by reducing 
traffic 
required 


for standard 
expansion 
boards on the industry.stan- 


dard MULTI BUS Interface. 


• Compatibility 
with future ll-bit and 16-bil single 


board computers 
from Intel 


• A high-reliability, 
36-pin iSBX 960-5 male connector 


for customer 
design 


drivers 
and terminators. 
The iSBX 351 Serial 1/0 
MULTIMODULE 
(see Figure 3) provides 
program- 
mable, 
synchronous 
/ asynchronous 
RS232C 
or 
RS4221 449 compatible serial expansion with fully soft- 
ware selectable baud rate generation. 
Additionally, two 


programmable 
16-bit 
BCD and binary 
timers 
are 


available, 
allowing 
iSBC 80/ lOB users to implement 


programmable 
timing functions directly on the board. 
A third 
MULTIMODULE 
board which 
users may 


select, 
provides 
additional 
on-board 
mathematics 


capability to their single board computer. The iSBX 332 
Floating Point Math MULTIMODULE board (see Figure 


New iSBX 960·5™ 
MULTIMODULE™ connectors 


are available off· the-shelf 


4) is compatible 
with the proposed IEEE format stan- 


dard. 
It offers single-precision 
(32-bit I and double- 
precision 
(64-bit) arithmetic 
functions 
including 
Add, 


Subtract, 
Multiply and Divide. It also includes end-of- 
operation 
and error interrupts 
to its host iSBC single 


board computer and full software reset controL 
User may easily implement 
their more specialized 


requirements 
on the new iSBX bus through 
a readily 


available 
36-pin 
male 
connector, 
the 
iSBX 960-5 


(packaged with 5 connectors). 
In addition, Intel is pro- 


viding an iSBX bus specification 
describing 
the elec- 


trical and mechanical 
parameters 
of the interface. The 


iSBX 960-5 male connectors mate directly to the female 
iSBX bus connector 
on the iSBC 80/ lOB single board 


computer. 
The connector, 
together with the iSBX bus 


specification, 
allows system designers to take full ad- 


vantage of MULTIMODULE benefits. 
New MULTIMODULES boards will be introduced- 


as will new generation iSBX bus compatible iSBC single 
board computers-by 
Intel throughout 
the remainder of 


1980 and into the future. MULTIMODULE boards and 
the iSBX bus represent a maior commitment 
by Intel for 


the future and offer system designers new options 
to 


complement 
single board computers 
and MULTIBUS 


expansion. 


The 
immediately 
available 
MULTIMODULE 


family-with 
the iSBC 80/IOB single board computer- 


provides great flexibility and savings for users 
The op- 


tions now exist to expand a system in small increments 
with MULTIMODULE 
boards, or in large increments 


with MULTIBUS boards. And, with the three dimen- 
sional expansion capability of the iSBC 80/IOB board, 
the user may configure his entire system on-board to 
achieve a single board, low cost solution. 


PRICE: 
Call your local Intel sales office or distributOr for 
thc latest prices on all of the MULTIMODULE 
products 
AVAlLABILlTY: 
Now 


LITERATURE: 
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Data Sheet 
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Data Sheet N IC 
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Data Sheet N IC 
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Special-function modules 
ride on computer board 


Smaller cards donate floating-point processing or added serial and parallel I/O 
to primary single-board computer; memory is extensible on the main card 


o In the 
design 
of board-level 
computers, 
two 
basic 
methods 
coexist. 
One 
is to pack 
each 
card 
with 
inte- 


grated 
circuits 
to the limits of its capacity, 
and the other 


is to distribute 
the 
computer 
functions 
among 
other 
boards occupying 
additional 
card slots. 


Both 
approaches 
have 
their 
advantages. 
The 
single 
powerful 
module 
conserves 
space and expensive 
connec- 


tors, 
while 
the 
decentralized 
boards 
allow 
the 
user 
to 


pick and choose 
functions-and 
add them 
incremental- 
ly-although 
the expense 
of one board 
might 
spell over- 


kill for one particular 
application. 
A new concept 
in single-board 
computer 
architecture 
strikes 
a neat compromise 
between 
both camps. 
Rather 
than 
cratn 
more chips on an already 
overstuffed 
board, 
the 
idea 
is simply 
to provide 
it with 
a connector 
for 
plugging 
in smaller 
modules 
having 
limited 
functions 
for 


specialized 
applications. 


Best of both worlds 


This 
is the 
idea 
behind 
iSBX 
Multimodule 
boards, 
which 
cost 
from 
$155 
to $450 
apiece. 
Plugging 
into a 


primary 
processor 
card, 
10.5-square-inch 
boards 
with 


various 
types of memory 
or input 
and output 
functions 


provide 
the larger 
single-board 
computer 
with more ver- 


satility. 
Linking 
the base board 
and these 
Multimodule 
boards 
is a new 
36-line 
bus called 
the 
iSBX 
bus, 
for 


single-board 
expansion. 
This 
interface 
is destined 
to 


match 
the popularity 
of the main board's 
Multibus 
inter- 


face connector 
(Fig. 
I). 


The 
iSBX 
bus is derived 
directly 
from 
the on-board 
microprocessor 
system 
bus 
and, 
as 
such, 
an 
iSBX- 


compatible 
board 
becomes 
an 
integral 
element 
of the 


single-board 
computer. 
The 
physical 
interface 
uses 
a 


unique 
connector 
designed 
specifically 
for the iSBX bus. 


The bus is brought 
to a female 
connector 
on the single- 
board 
computer; 
its male 
equivalent 
is resident 
on the 
iSBX board (Fig. 2). 


The 
iSBC 
80/IOB 
board 
in Figs. 
I and 
2 is the first 


single-board 
computer 
to be compatible 
with the iSBX 
bus. Upwardly 
compatible 
with its predecessor, 
the iSBC 
80/ IDA, the iSBC 80/1 DB is functionally 
equivalent 
but 


offers significant 
enhancements. 


The 
iSBC 
80/ IDB 
board 
offers 
direct 
functional 
expansion 
in three dimensions- 
not only read-only 
mem- 
ory (as in the 
iSBC 
80/IOA), 
but also static 
random- 


access 
memory 
and 
input 
and output, 
as facilitated 
by 
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the Multimodule 
boards. 
One 
kilobyte 
of static 
RAM 
is 


provided 
along with sockets 
for expansion 
in increments 


of l-K bytes to 4-K bytes using standard 
2114A-5 
memo- 


ries. Read-only 
memory 
may be expanded 
with s'tandard 


ultraviolet-light-erasable 
and mask-programmable 
types 


to 16-K bytes. 
The 
iSBC 
80/IOB 
also 
features 
an 
on-board 


1.04-millisecond 
timer 
with ongoing 
clocking 
that 
users 


may optionally 
configure 
for microprocessor 
interrupts. 


In addition, 
power-fail 
control 
is provided 
for the 2114A- 


5 static 
RAMS, 
enabling 
the user to add battery 
backup 
if 
the memory 
contents 
must be preserved. 


Three Multimodule 
boards 


Being 
introduced 
along 
with 
the 
iSBC 
80/ IDB are 


three 
M ultimodule 
boards 
that 
expand 
the 
functional 


capacity 
of the single-board 
computer. 
Two of these, the 


$155 
iSBX 
350 and $230 
iSBX 
351, provide 
the same 


kind of input/output 
functions 
as are to be found on the 


processor 
board, only more of them. 


For example, 
the 48 programmable 
110 lines on the 


iSBC 
80/ IDB board 
may 
be expanded 
to 72 lines 
by 


simply 
plugging 
in 
the 
iSBX 
350 
module-a 
50% 


increase. 
Serial 
I/O is similarly 
expanded 
with the iSBX 


351 module, 
which 
provides 
a programmable 
universal 


synchronous-asynchronous 
receiver/transmitter, 
or 


Usart 
(an 8251 A), for compatibility 
with the RS-232-C 


and 
RS-449/422 
interfaces. 
The iSBX 
351 module 
fur- 


ther 
offers software-selectable 
baud 
rates 
and 
two pro- 


grammable 
16-bit 
binary 
or 
binary-coded 
decimal 


timers, 


The third 
Multimodule 
board 
adds otherwise 
unavail- 
able 
high-speed 
math 
capabilities 
to the 
iSBC 
80/IOB 


board. The $450 iSBX 332 board 
uses the 8232 f1oating- 


point processor 
for arithmetic 
compatible 
with the stan- 


dard currently 
being proposed 
by the Institute 
of Electri- 
cal and Electronics 
Engineers. 


Many 
applications 
require 
a custom 
design. 
To com- 


plement 
the standard 
family of Multimodule 
boards, 
the 


iSBX 
960-5 
is provided, 
This 
includes 
five male 
iSBX 


connectors, 
and a full bus specification 
is available 
for 


custom 
interfacing 
by the 
user. 
This 
combination' 
per- 


mits a user to satisfy 
his or her requirements 
for special- 


ized I/O interfaces 
with the Multimodule 
concept. 


The 
Multimodule 
concept 
can 
be divided 
into 
two 


logical 
clements: 
base boards 
and 
Multimodule 
boards. 


RS 232 C 


COMPATIBLE 


OEVICE 


SlRIAl 
OATA 
CONTROL 


INTERFACF 


SERIAL 
OATA 
CONTROL 
INTERFACE 


L. 


JUMPER 
• tj 


SELECTEO 


1.04 lllS 


INTERVAL 
TIMER 


USER·O ESIGNATEO 
,SBX MULTIMOOULE 


BOARD 


48 PROGRAMMABLE 
PARALLEL 
INPUTI 


OUTPUT LINES 


DRIVER/ 


TERMINATOR 
INTERFACE 


,SBX BUS 


MULTIMOOULE 
CONNECTOR 


SOCKETS FOR 
16KBY8BIT 


READ ONLY 
MEMORY 


OR ERASABLE 
PROGRAMMABLE 
ROM 


I K-BY·8 
BIT 
RANDOM 
ACCESS 
MEMORY 


ISOCKETS TO 
4 K ·BY·B BITS) 


PROGRAMMABLE 


COMMUNI· 
CATIONS 


INTERFACE 


IUSART) 


80BOA 


CENTRAL 
PROCESSING 
UNIT 


PROGRAMMABLE 
PERIPHERAL 
INTERfACES 


1. Distributed. 
The first processor 
CArd 10 receive the ISBX bus connector 
is the iSBC 80/ 
10B. a follow-on 
~o the iSBC 
80/10A. 
The off-board 


system 
bus IS the Multlbus. 
which Interfaces 
to the on·bo;nd 
system 
bus. This. in turn. connects 
to the Multimodule 
board connector 


The 
bas.: boaFd is th.: master 
of the system 
in that 
it 
control, 
communication 
b.:tween 
th.: bas.:'s micmpmccs- 


sor and th.: Multimodule 
board's 
port. Though 
the lirst 
base 
board 
is 
a 
singk-board 
computer 
the 
iSRC 


lWIIOR 
Multibus-compatibk 
slaves and intelligent 
I/O 
boards 
will also 
incorporate 
iSHX 
bus 
inl.:rfac.:s. 
Th.: 
Multimoduk 
board 
is a slav.: of th.: system 
in that 
it 


earri.:s out I/O commands 
fmm th.: base board. 


The 
iSBX 
bus specilication 
inelud.:s 
both 
electrical 


and 
m.:chanical 
characteristics. 
The 
mechanical 
int.:r- 
face is conv.:nient 
and rugged: 
the M ultimoduk 
board 
is 
mounted 
to the base board 
in two places. at the top with 


a screw and at th.: bottom 
by the iSBX 
bus connector. 
The 
connector 
is extremely 
reliable. 
II has gold-plat.:d 


phosphor-bron!.: 
contacts. 
it is keyed 
to assure 
proper 


orientation. 
and 
a shmud 
protects 
its pins during 
han- 


dling. 
Thc connector 
also incorporatcs 
intcrlocking 
tabs 
10 ensure a solid mechanical 
interface. 


Electrically. 
the 
iSBX 
bus 
int.:rface 
lines 
can 
be 


Electronics/ 
April 10. 1980 


grouped 
into 
six 
e1asses 
conlrol. 
address 
and 
chip 


sekct. 
data. 
interrupts. 
options. 
and 
power 
for a total 
of 36 signal lines. 
Control 
lines can 
be further 
grouped 
into 
those 
for 
commands. 
initiali!ation. 
a e1ock. and 
system 
control. 


The 
two 
command 
lines 
(IORD/ 
and 
10WRT/) 
arc 


aclive-Iow 
I/O-read 
and 
-write 
signals 
that 
control 
thc 


communication 
link 
betwecn 
thc 
basc 
board 
and 
the 


Multimodule 
board. 
With a chip-select 
signal. 
an active 


command 
linc indicatcs 
that 
thc address 
lines arc 
valid 
and that the Multimodulc 
board 
should 
pcrform 
a speci- 


licd operation. 


The 
initialize 
line (r.:sct) 
is an active-high 
input 
linc 


from 
thc 
base 
board 
that 
puts 
thc 
Multimodule 
board 


into a known intcrnal 
state. 
The clock line (Mel K) has a 


fre4uency 
of 10 megahertz. 
+()'/, or -IO'/'. 
Hcing asyn- 


chmnous 
with respcct 
to all olhcr 
Multimoduk 
signals. 


Ihis fre4ucncy 
can vary from base board to base board. 


The 
rcmaining 
control 
lincs. 
MWAIT/ and 
MPST. arc 


output 
signals 
from the Multimodule 
board 
that control 


the 
state 
of thc systcm. 
MWAIT/. active 
low. puts 
the 


2. Three 
10 one. 
Below 
is the iSBC 801 10B main 
processor 
board. 
and above 
It are the three 
new 
Multlmodule 
boards. 
They 
are. 
tram 
left to 


right. 
the ISBX 351 serial 
110 module. 
the LSBX 
350 parallel 
110 module. 
and the iSBX 332 floating-point 
mathematics 
Multlmodule 
board. 


base-board 
processor 
into 
a 
wait 
state, 
allowing 
the 


Multimodule 
board 
extra 
time 
to perform 
a requested 


operation, 
if 
necessary. 
MWAITI 
is 
generated 
from 


address 
and chip-select 
information 
only. MPST is tied to 


ground 
on the 
Multimodule 
board 
to inform 
the 
base 
board that a M ultimodule 
board 
has been installed. 
The 
second 
class 
of 
iSBX 
bus 
lines 
includes 
the 


address 
lines 
(MAo-MA,) 
and 
the 
chip-select 
lines 


(MCSol 
and 
MCSJ/). 
The 
base 
board 
decodes 
1/0 


addresses 
to 
generate 
the 
chip-select 
signals 
for 
the 
Multimodule 
boards. 
In'so doing, it normally 
decodes 
all 
but 
the 
three 
lowest-order 
addresses 
(MAo-MA,). 
A 
base 
board 
normally 
reserves 
two blocks 
of eight 
110 
ports for each iSBX bus connector 
provided. 


Defining the lines 


Eight 
bidirectional 
data 
lines 
(MDo-MD" 
active 
high) 
carry 
information 
to and 
from 
the 
Multimodule 


ports. 
MDo is the 
least 
significant 
bit. The 
two active 
high 
interrupt 
lines 
from 
the 
Multimodule 
board, 
MINTRo 
and 
MINTR" 
make 
interrupt 
requests 
to the 
base board: 


Two optional 
lines, OPTo and OPT" 
are connected 
to 


wire-wrapped 
posts on both 
the base and 
Multimodule 
boards. 
They 
may 
serve 
either 
as additioniil 
interrupts 
from the 
M ultimodule 
board 
or as special 
signals 
from 
the base board. 
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Finally, 
all base boards 
provide 
+ 5 and ± 12 volts to 


the Multimodule 
boards. 
These 
power lines complete 
the 


six iSBX bus classes. 
The primary 
function 
of the iSBX 
bus is to provide 
a 


path 
for I/o-mapped 
data 
between 
base board 
and Mul- 


timodule 
board. 
This happens 
when the base board 
per- 


forms an I/O-read 
or 1I0-write 
operation. 
There 
are two 


types 
of 
1/0-write 
operations, 
and 
the 
Multimodule 


board determines 
which is performed. 


Data transfers 


The 
first is a full-speed 
1/0 write 
(Fig. 
3). The 
base 


board 
generates 
a valid 
110 address 
and chip-select 
and 


activates 
the 10WRTI line after 
the set-up 
times are met. 


The 
10WRTI line will remain 
active 
for a minimum 
of 


300 nanoseconds 
and the data 
will be valid 
for a mini- 


mum 
of 250 
ns before 
10WRTI is removed. 
The 
base 


board 
then 
removes 
the 
data, 
address, 
and 
chip-select 


signals after the hold times shown in the timing diagram. 


The 
alternative 
1/0 
write 
is 
a 
write-with-wait, 


used by Multimodule 
boards 
that 
cannot 
write 
into an 


1/0 port at full speed. Again, 
the base board 
generates 
a 


valid 
address 
and 
chip-select. 
The 
Multimodule 
board 


activates 
the MWAITI signal 
based 
on address 
and chip- 


select 
information. 
This will remove 
the ready 
condition 


from the processor, 
causing 
it to go into a wait state after 


the 
write 
command 
has been 
activated 
and 
valid 
data 


ADDRESS 
IMI\o-MA,) 


CHIP SELECT 
IMCS,) 


3. Write 
types. Two modes of sending information to a Multimodule board are available: full-speed and with a wait state. The wait line is not 
used for peripherals that meet the full·speed specifications. The wait signal extends the time for which data remains valid. 


provided. 
The 
Multimodule 
board 
will 
remove 
the 
MWAIT/ signal-allowing 
the processor 
to leave its wait 


state-when 
it 
has 
satisfied 
the 
write-pulse-width 


requirement. 
The 
base 
board 
removes 
the 
write 
com- 


mand, 
then 
the 
data, 
address, 
and 
chip-select 
signals, 
after the hold times are met. 


There are two types of I/O-read 
operations 
as well, and 


again 
they 
are 
determined 
by the 
Multimodule 
board. 
The 
first 
is a full-speed 
I/O read 
(Fig. 
4). 
The 
base 
board 
generates 
a valid 
I/O address 
and chip-select 
and, 


after 
the set-up 
timings 
are met, 
it activates 
the 10RD/ 
line. The 
Multimodule 
board 
must 
generate 
valid 
data 
from the addressed 
I/O port in less than 250 ns. The base 
board 
reads 
the 
data 
and 
removes 
the 
command, 
address, 
and chip-select 
signals as indicated 
in the timing 


diagram. 


Read-with-wait, 
whose timing 
is at right 
in Fig. 4, is 
used by Multimodule 
boards 
that cannot 
perform 
a read 


operation 
under 
the 
full-speed 
specifications. 
The 
base 
board 
generates 
a valid address 
and chip-select, 
just 
as 
with a full-speed 
read. 
However, 
the Multimodule 
board 


now activates 
the MWAIT/ signal, 
which in turn 
removes 
the ready 
input to the base's 
processor, 
putting 
it into a 
wait 
state. 
The 
processor 
activates 
the 
10RD/ signal 
before going into a wait state. 


The 
Multimodule 
board 
will remove 
the MWAIT/ sig- 


nal when valid data can be read from the data 
bus. After 


reading 
the data, 
the base board 
removes 
the command, 


address, 
and chip-select 
signals. 
The 
iSBX 
351 serial 
I/O board 
is a good example 
of 
how easily 
large-scale 
integrated 
circuits 
may be inter- 


faced 
by the 
iSBX 
bus. 
It presents 
the 
iSBC 
80/ IOB 


ADDRESS 
(MI\o-MA,) 


CHIP SELECT 
IMCS,l 


110 READ 
(lORD) 
:< VALID 
DATA 
P:ci:_B~g71 ------<XXXXXXlOOO6OC 
:.,.••----- 


board with a second serial port. 


The iSBC 
351 board 
(Fig. 
5) provides 
a synchronous 


or 
asynchronous 
serial 
communications 
channel 
with 


programmable 
format 
and 
baud 
rates 
up to 64 kilobits 


per second. 
In the synchronous 
mode, the user selects via 
software 
the number 
and format 
of the synchronization 
characters 
and the number 
of data 
bits. 
Parity 
may 
be 


even, odd, 
or disabled. 
In the asynchronous 
mode, 
the 


number 
of data 
bits 
and 
stop 
bits, 
as well 
as 
parity 


generation 
and 
detection, 
may 
be specified 
under 
pro- 


gram 
control. 
The 
added 
channel 
is compatible 
with 


either the RS-232-C 
or RS-422/449 
interface. 


Two additional 
16-bit counters 
are on the 
board 
for 


other 
uses. Their 
mode of operation 
and count value may 


be written 
or 
read 
under 
program 
control. 
With 
the 


interrupt 
lines provided 
by the iSBX bus, they may also 


be used as real-time 
interrupt 
sources 
(see Table 
I). 


As stated 
earlier, 
an 8251 A Usart 
gives the iSBX 351 


module 
a high-performance 
communications 
channel. 
In 
addition, 
an 
8253 
programmable 
interval 
timer 
(PIT) 


provides 
the 
three 
counters 
for 
clock 
generation 
and 


timing. 
Note 
in the 
block diagram 
of Fig. 5 that 
both 


devices 
are connected 
directly 
to the data, 
address, 
and 
command 
buses 
with 
no buffers. 
(Each 
chip, 
however, 


has its own chip-select 
line, preventing 
data 
bus conten- 
tion.) The absence 
of buffers 
keeps the parts count down 
and the speed up. 
Also shown in the extra 
block diagram 
are two option- 
, 


al lines that may be used as additional 
interrupt 
lines or 
to interface 
to the additional 
timer/counters. 
There 
are 
four 
interrupt 
sources 
on 
the 
board. 
Two, 
from 
the 
8251 A, indicate 
either 
that a character 
has been received 


4. Read 
type •. 
As in writing data 
into a Multimodule 
board. 
information 
is read from it in one of two ways: full speed 
or read-with-wait. 
The wait 


state extends 
the length of time that data is valid. This is necessary 
for slower transactions 
such as analog-to-digital 
conversions. 


8253 
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INTERVAL 
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RS·232-C 
AND 
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INTERFACE 
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5. More serial I/O. 
The 
iSBX 
351 
serial 
inputl 
output 
Multimodule 
board 
provides 
the 
base 
processor 
with 
an additional 
synchronous 
or 


asynchronous 
communications 
channel- 
one that 
is compatible 
with 
either 
the RS-232-C 
or the RS-422 
/ 449 
intertace 
specifications. 


for reading 
or that 
the transmitter 
buffer 
is empty 
and 
ready 
for 
transmission. 
Two 
other 
interrupts 
may 
be 
generated 
by the timer/counters. 
The timers 
count 
from 


an on-board 
crystal-controlled 
oscillator. 


Compatible 
with both 


The 
iSBX 
351 module 
uses a unique 
split-edge 
con- 


nector 
to provide compatibility 
with both RS-232-C 
and 


RS-449 
interfaces. 
RS-232-C 
is commonly 
used to com- 


municate 
with terminals, 
modems, 
and other 
equipment 


up 
to a distance 
of 
50 
feet 
away. 
RS-422 
is a new 


interface 
that 
allows 
high-speed 
data 
transfers 
of up to 


4,000 
feet 
through 
differential 
lines 
that 
reduce 
noise 
such 
as 
crosstalk. 
The 
iSBX 
351 
module 
is the 
first 


expansion 
board to offer both interfaces. 
The 
iSBX 
351 module 
is programmed 
by a series 
of 
I/O-read 
and 
-write 
commands. 
Table 
2 shows 
the 
I/O 
port assignments 
on the iSBC 
80/ IOB board 
by way of 


explaining 
the code sequences 
in Table 
3 that 
run on it. 


The first routine 
in Table 
3, INIT, initializes 
the 825lA 


for asynchronous 
operation 
and 
programs 
the 
8253 
to 


generate 
a baud 
rate 
of 9,600. 
XMIT takes 
a character 


from 
the 
C register 
of the 
8080A 
and 
sends 
it to the 
Usart 
for transmission. 
RECV gets a character 
from the 
Usart and places it in the accumulator. 
Note that in both 


data-transfer 
routines 
the Usart 
status 
register 
is check- 


Electronics/ 
April 
10. 1980 


ed to ensure 
proper operation. 


The iSBX 350 programmable 
I/O Multimodule 
board 


provides 
24 general-purpose 
1/0 
lines 
(or 
three 
8-bit 


ports) 
via a standard 
50-pin 
edge connector, 
giving 
the 


iSBC 
80/ IOB a total 
of 72 I/O lines. The 
8255A 
is the 


only 
LSI component 
on the 
board, 
and 
six sockets 
are 


provided 
for line drivers or terminators. 


Two bidirectional 
inverting 
4-bit 
bus transceivers 
are 


provided 
for one of the three 
ports; sockets 
for the other 


two are 
TTL-compatible, 
allowing 
the 
use of inverting, 


noninverting, 
or open-collector 
drivers. 
When 
either 
of 


these other 
two ports 
is used as an input, 
the lines may 


be terminated 
either 
with 
I-kilohm 
pullup 
resistor 
packs 


or with 220/330-ohm 
pullup/pulldown 
resistors. 


TABLE 
1 
,SBX 
351 
SERIAL 
INPUT 
OUTPUT 
BOARD'S 


BAUD 
RATES 
AND 
INTERVAL 
TIMES 


Minimum 
values 
Maximum 
values 


Baud 
18.75 
bauds 
64 
kilobauds 


generator 
(limited 
by 
8251 
AI 


Single 
timer 
1.63 
"' 
428 ms 


Dual cascaded 
3.26 
"' 
7.8 
h 
timers 


Universal 
data 
port 
FO. F2. F4. or F6 
Command 
Mnemonic 
synchronous. 
type 


asynchronous 
control 
port 
Fl. 
F3. F5. or F7 


receiver· 
transm 
it ter 


32·bit 
SADD 


Timer 
counter 
0 
F8 
or 
FC 


counter 
1 
F9 or 
FD 
32·bit 
SSU8 


counter 
2 
FA 
or 
FE 


control 
port 
FB or 
FF 
32 
bit 
SMUL 


32-bit 
SDIV 


INT: 
MVI 
A.96 
Mode 
word 
to 8253 
counter 
2 


OUT 
OF8 


MVI 
A. 8 
Divide 
value 
to 8253 
counter 
2 


OUT 
OFA 


MVI 
A. 
OFE 
Mode 
word 
to 8251 
A Usart 


OUT 
OFt 


MVI 
A. 27 
Command 
word 
to 8251 
A 


OUT 
OFt 


RET 


XMIT: 
IN 
OFt 
Check 
Usart 
status 
to make 
sure 
It's 


ready 
to transmit 
a character 


ANI 
01 


JZ 
XMIT 
Loop 
until 
ready 


MOV 
A. C 
Get 
data 
character 


OUT 
OFO 
Send 
it 


RET 


RECV: 
IN 
OFt 
Check 
Usart 
status 
to see If a new 


character 
has been 
received 


ANI 
02 


JZ 
RECV 
Loop 
until 
data 
is available 


IN 
OFt 


ANI 
38 
Check 
framing, 
overrun, 
and 
parity 


error 
bits 


JNZ 
ERROR 
Jump 
to an error 
handler 
If there 


are any 
problems 


IN 
OFO 
Get 
data 


RET 


The 
iSBX 
350 
module 
supports 
all 
three 
8155/\ 
modes: 
basic 
I/O. strobed 
110. and strobcd 
bidirectional 


bus I/O. Sevcral 
or the handshaking 
signals arc available 
as interrupt 
sources. 
and an additional 
external 
interrupt 
may be brought 
in via the edge connector. 
Programming 
this board 
is as simple as programming 
the 
8255/\s 
on the 
iSBC 
80/IOB 
itsclr. 
First. 
a mode 


word is written 
to the control 
port to speciry 
the opera- 


tional 
mode ror each port. Data transrer 
may then begin. 
in the rorm or I/O-read 
or -write operations. 
The 
iSBX 
332 
module 
is an accurate 
32- or M-bit 


floating-point 
processor 
that 
perrorms 
arithmetic 
opera- 


tions in accordance 
with the proposed 
IEEE floating-point 


standard. 
It uses the 8232 floating-point 
processor. 
The 
math 
module 
uses one data 
format 
that 
has two 
word 
lengths 
or 
31 or 
64 
bits. 
The 
board 
will 
add. 
subtract. 
multiply. 
and 
divide 
ror 
both 
word 
lengths. 
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64 bit 
DADD 


64 
bit 
DSU8 


64 
bit 
DMUL 


64 
bit 
DDIV 


CLR 


32 
bit 
CHSS 


64 
bit 
CHSD 


32-bit 
PlOS 


64-bit 
PTOD 


32 
bit 
POPS 


64-bit 
POPD 


32·blt 
XCHS 


Table 
4 shows the instruction 
mnemonics 
and runctions, 


as well as the positions 
in the stack 
(top or stack or next 
on staek) 
the operands 
and results occupy. 


The 8232 runs at 4 MHz 
ror maximum 
throughput. 
/\ 


multiplication 
or two 
32-bit 
quantities 
takes 
about 
50 


microseconds, 
excluding 
data 
entry 
and 
retrieval. 
In 
addition. 
two interrupts 
signal 
the base-board 
processor 


or completion 
or an operation 
or an error. 


Floating-point math 


The 
two word 
lengths 
or the 
floating-point 
standard 
were chosen 
ror the highest 
speed and accuracy. 
Ir speed 


is 
the 
primary 
objective. 
the 
32-bit 
rormat 
gives 
a 


dynamic 
range or approximately 
10.38 to 10+38. 
Ir range 


and 
accuracy 
arc 
required. 
the 
64-bit 
rormat 
spans 
in 
execss 
or 10+300 
to 10.300. 
This 
wide dynamic 
range. 
in 


conjunction 
with 
highly 
accurate 
rounding 
algorithms. 


renders 
thc iSBX 
331 module 
ideal 
ror scientifie 
prob- 
lems and other 
applications 
requiring 
high speed. 
aecu- 


racy. and ra nge. 
0 


inter 
ARTICLE 
REPRINT 


MULTIPROCESSING 
SYSTEM MIXES 
8- AND 16-81T MICROCOMPUTERS 


Combining different single-board computers on a single 
bus and assigning to each the tasks most suited 
enable a cost-effective multiprocessing system configuration 
with improved throughput 
and reliability 


Two 
or more single-board 
computers can share a com- 


mon 
system 
bus 
to 
provide 
improved 
performance, 
reliability, 
and 
cost-effectiveness 
in 
medium 
to 
large 


scale applications. 
Interfacing 
multiple computers 
across 
a system bus affords a dual-bus 
architecture 
in which 


global system traffic is isolated from local traffic on the 
board 
buses. 
This 
allows 
a straightforward 
design 
of 
modular 
multiprocessing 
systems that combines different 


computer 
boards, 
and allocates to each that portion 
of 
the overall system function to which it is best suited. 


In a typical 
design, 8- and 
16-bit single-board 
com- 
puters 
(SBCS) communicate 
across a system bus to ser- 


vice an application 
that requires 
both realtime data ac- 
quisition 
and 
extensive 
signal 
processing. 
Partitioning 


system tasks and assigning 
each to the appropriate 
SBC 


optimizes performance 
without adding components. Dual- 


port memory 
provides 
a convenient 
way to synchronize 


processes on different 
SBCs. Because most system func- 


tions are isolated on one SBC,reliability 
and throughput 
are increased, and implementation 
is facilitated. 


In earlier 
SBCdesign, the fundamental 
goal was to pro- 


vide a board containing 
all the resources 
required 
for a 


large variety 
of microprocessing 
applications. 
A typical 
processor 
board 
supplies an 8080A processor, 
4k bytes 


of random 
access memory 
(RAM), 
sockets for up to 8k 


bytes of erasable programmable 
read only memory/read 


only memory 
(EPRO~f/ROM), 
a serial input/output 
(I/O) 


interface, 48 parallel 
I/O lines, three timer/counters, 
and 


eight 
levels of priority 
interrupt. 
With 
this 
hardware 
configuration, 
many 
small 
applications 
can 
be 
served 


with no need for additional 
memory or digital logic. 


<=--- 


Bf'('aus(~ 
larger 
appli('atioll~ 
require 
additional 
I't>- 


sources. 
an 
external 
hus 
structure 
was 
defined. 
The 


\IlI.TlBl 
~nl 
s)'~t{"m uus 
\\as 
dt'~ignt'd 
(<II' communication 


hel\\t't'n 
SHes ano 
system 
eXpi.lll:-,iOl) 
h()ard~. 
Addre~s. 
data. 
and 
hand,hake 
lines 
"ere 
defined 
for 
memory 
and 
I 0 
transfers 
hetween 
sHes 
and 
expansioll 
hoards. 
There 
art' 
hus 
expansion 
boards 
for 
system 
e~pansioll 
in 
area~ 
of 


HAM and 
RO'I 
storage. 
serial 
and 
parallel 
1 O. allalo~ 
10, 
and 
peripheral 
controllers. 


In 
Fig 
1,1\\0 
huses 
interconnect 
a sy~tem 
"ilh 
an 
sHe 
ann 
two 
exp3nsiorJ 
h()ard~. 
;\n 
onhoard 
hu:-, 
a('('e:-,~e~ 
local 
re~our('es. 
and 
the 
sys1l'm 
bu~ 
<\n'(':"\st>:-i ;..dohal 
H-'· 
Sources. A key 
«(h-anlage 
of Ihi~ structure 
is that 
an sHe 
may 
not 
requirt' 
the 
s)'stt'm 
hus 
for 
a large 
portion 
of it:- 
memory 
or 
I 0 transactions. 
In 
many 
appli('ationf-;, 
It"~:-' 


than 
10'; 
of 
the 
time 
is taken 
hy 
~Y:-.tt"m hu~ 
a('ce~:-:t"~. 
The 
large 
anlount 
of potential 
~YSI~m 'I)ll~ capacity 
makt:':-' 
this 
architecture 
a nalural 
cancii(latt' 
for 
muhipr()ce:-;:-;il1~ 
applications. 
As 
adciitiollal 
~BC~ 
are 
included 
in 
tilt' 
~y:-;- 
tern, 
tht~ 
incrt'mental 
amount 
of 
!"oy~tem hu~ 
hall(h\ 
idt h 


required 
i> u>ually 
,mall. 


Certain 
~ystem 
applications 
benefit 
from 
usill~ 
mort' 
than 
a single 
SHC. Moti\Oations 
for 
constructing: 
muhipro('e:-,~in~ 
systems 
with 
SBes 
include: 


Resource 
sharin{!.. In 
a multiprocessing: 
sy!"otem desi~ned 


around 
the 
resource 
sharinf!; 
concept, 
two 
or 
more 
pro- 


cessor 
boards 
share 
a common 
resou rec. 
such 
as 
a high 


MEMORY 


EXPANSION 
BOARD 


Fig 1 
Single 
SBC system 
with 


two 
expansion 
boards. 
CPU 


oses 
data 
path 
1 
to 
access 


local 
memory 
and 
I/O, 
and 


data 
path 
2 to access 
expan- 
sion boards 
on MULTIBUS sys- 


tem 
bus 


I/O 
EXPANSION 
BOARD 


>peed 
mathematics 
board 
or 
a 
peripheral 
controller. 


The,e 
hoards 
perform 
independent 
functions 
with 
no 


relalio'I'hip 
to 
one 
another 
except 
for 
the 
shared 
re- 


~ource. 
Lo\\ 
cost 
is 
the 
obvious 
motivation 
for 
using 
a 


resource 
sharing 
multiprocessing: 
configuration. 
If 
two 


proce:,,~or 
hoards 
share 
the 
same 
diskette 
controller, 
for 


e,ample. 
0' erall 
,yslem 
costs 
are 
considerably 
reduced. 


E,dwllrl,t! 
syslt~m 
throu/d,put 
and 
performance. 
In 
many 


applications. 
~i:.nlificant 
improvements 
in 
performance 


may 
he 
cu,hit'\{·d 
hy 
u:••ing 
more 
than 
one 
processor 
in 


tht' 
~y~tt'm. 
'1'\\0 
\\ay~ 
of 
allocating- 
or 
lJartitionin~ 
sys· 


kill 
fUII('tion~ 
among 
multiple 
processors. 
such 
as 
pipe· 


lillt' 
and 
parallel 
partitioning. 
are 
5oho\\ n in Fig 
:2. In pipe· 


lint' 
partitionin:..r. 
system 
functions 
Itasks 
I 
are 
divided 


amon:..r 
~t'\ t'ral 
pro(.'e~sors. 
so 
that 
data 
flo\\ 
through 
the 


:"'~!"i1t'1ll i~ primarily 
:"erial. 
F:ach 
processor 
performs 
it~ 


portion 
of 
~y:-.tem 
fUJlction!"i. 
and 
then 
calls 
UpOIl 
an- 


otllt'1" 
proct'!"i:"or 
to 
perform 
.another 
set. 
An 
example 
of 


pipt·line 
partiti()nin~ 
i~ "hen 
one 
processor 
performs 


data 
i.lcqui:"ition 
and 
huffering. 
while 
a second 
uses 
the 


data 
to 
perform 
(li~ital 
signal 
processing. 


Parallel 
partitioning 
allocatt"~ 
~y:,;;tern functions 
among 


:o"t'\eral 
prO('e~~or~ 
in ~uch 
a \\ a~ that 
each 
processor 
per· 


forms 
a ~eparate 
:-oy~tt"m task 
in 
parallel. 
An 
example 
is 


a 
system 
\\ Ilt're 
olle 
proce~sor 
performs 
an 
industrial 


pro('t'~:" 
('ontrol 
loop. 
\\hile 
another 
monitors 
and 
con· 


tr(ll~ 
a \ arying 
paramder. 
such 
a:-. temperature. 


Fe" 
,y,tem, 
ma) 
he 
characterized 
as 
totally 
parallel 
or 
pipe/illt' 
partitiullt:'cL 
hut 
designating 
systems 
in 
this 


mallller 
can 
often 
he 
he1pf ul 
during 
the 
system 
design 


pha:-,/:'. 
particularly 
\\ hen 
interprocessor 
communication 


~ofl \\ are 
j~ heill~ 
clesip;lled. 


I/mlu/art:r 
confil!ured 
s')·stems. 
A 
primary 
de!;i~,!,'fl goal, 


particularly 
in ~Y5tems 
that 
are 
produceo 
in 
10\\ 
\olume, 


[ 
8086 


Fig 4 
Intelligent slave archi- 


tecture. 86/12A and intelligent 
slave board 
544 communicate 


using dual-port RAM 


------ 
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The iSBC86/12A 
single.board 
computer' 
has many of the 
architectural 
features 
of B·bit hoards 
Iserial 
and parallel 


I 0, multiple 
interrupt 
levels, 
and 
timer/counters 
I but 


includes 
a 
5·MHz 
gOB6 
microprocessor 
and 
larger 


amounts 
of 
R'M 
and 
EI'RO" ROM storage. 
The 
16·hit 


aOB6 permits 
byte 
and 
word 
transfers, 
hardware 
multi- 


ply divide, 
lM·byte 
addressability, 
extensive 
string 
ma- 
nipulation 
instructions, 
and 
many 
other 
features. 
The 
go 12A contains 
;{2k hytes of dual port RAMand sockets 
for up to 16k bytes of EPROM/ROM,douhling 
the memory 
availahle 
on previous 
hoards. 
If more 
HAM 
or 
EPI{OM 
HOM 


storage 
is 
required, 
memory 
expansion 
modules 
permit 


doubling 
RAM and/or 
EPROM/HOMstorage 
to 64k bytes 
of R'M and 12k bytes of EPROM/ROM. 


Memory 
expansion 
modules 
are 
small 
printed 
circuit 


boards 
that attach 
to the B6/12A 
board 
using sockets and 


nylon 
holts. 
l'se 
of 
the 
expansion 
modules 
is advan. 


tageous 
from 
a price/performance 
point 
of view. Price 
of either 
of the memory 
expansion 
modules 
is significant- 
ly Jess than 
that 
of an equivalent 
separate 
memory 
ex· 
pansion 
hoard 
with 
its 
own 
system 
hus 
interface 
ancl 


support 
circuitry. 
Memory 
expansion 
modules 
also offer 


higher 
performance 
since 
it 
is 
not 
necessary 
to 
use 
the 


system 
hus 
for 
memory 
transactions. 
A II 
transaclions 
tak.· 
place 
using 
the 
onboard 
hus 
with 
no 
additional 


,\oait 
~tates or hus contention. 


Thp 
HOBo microprocessor 
performs 
g- or 
1v-hit 
transfers 


to or from memory 
or 
I{ 0 devices. 
When a hyte 
Ig·hit) 
transfer 
is requested from an even address, dala are prp- 


sented to the microprocessor 
on its low order 
data 
lines, 


DO through 
D7. When a byte transfer 
is requested 
from 


an odd 
address, 
data 
transfer 
must 
occur 
on the 
high 
order data lines, DB through 
D15. When a 16·bit (word) 


transfer 
is requested, 
data are transferred 
on all 16 data 


lines, 
DO through 
1)15. When 
an 
8·hit 
microprocessor 


I BOnOA 
or 
aOB5A) 
is 
used, 
however, 
all 
byte 
transfers 


must take place on data 
lines DO through 
D7, the only 


lines available. 
To maintain 
compatibility 
between 
boards 
with 8-bit 
and 16-bit processors, 
a system bus transfer 
protocol 
has 


been 
developed 
where 
all byte 
transfers, 
regardless 
of 
\\ hether 
from 
an 
odd 
or 
even 
add ress, 
take 
place 
on 


the 
low order 
system 
bus 
data 
lines, 
DATO/ to DAT7/; 


word transfers, 
however, 
use all 16 data 
lines, DATO/ to 
DATF/. To 
accomplish 
these 
byte 
transfers, 
an 
8-bit 


huffer is used on 16-bit master and slave boards 
for trans- 


ferring 
data 
from the high order 
data lines on the board 


to the low order 
data 
lines of the system bus. An addi- 


tional 
signal 
line, byte 
high 
enable, 
(BIIEN/) 
indicates 


whether a word transfer 
is taking 
place on the high order 
and 
low order 
data 
lines or whether 
a byte transfer 
is 


taking 
place 
only 
on 
the 
low order 
data 
lines. 
Fig 
5 


illustrates 
8- and 16-bit transfers 
and the use of the ad- 


ditional 
huffer for transferring 
the sil';nal to or from the 


high order data byte. 


/\ data 
acquisition 
and 
signal 
processing 
system 
design 


demonstrates 
the capabilities 
of a multiprocessing 
system, 


\\ here improved 
performance 
is mandatory. 
General 
ap· 
plication 
of the 
system 
is power 
spectrum 
analysis 
of 


\ ihratio/l 
and acoustic 
signals. 
Application 
areas for such 


these interrupt 
lines can be used for communication 
be- 


tween master SBCboards. 
Individual 
master boards may 
either generate 
interrupts 
or he interrupted 
from one or 


more of the interrupt 
lines. Interprocessor 
interrupts 
pro- 
vide a fast and effective way for multiple SBCsto com- 
municate over the system bus. 


Dual-Port 
Memory 


Single-board 
computers have been designed with onboard 


RAMcontaining 
two access ports. Dual access ports per- 


mit the onboard CPUto access the RAMdirectly using the 
onboard 
bus. Other SBCsalso access the RAMusing the 
system bus. The amount of memory available for system 
bus access may be selected from all memory accessible to 
no memory accessible, in increments 
of one-half or one- 
quarter 
of available 
memory size. This ability to block 
RAMaccess from the system bus provides 
memory 
pro· 
tection for data and code stored in those non accessible 
areas of the dual-port 
RAM.Fig 3 illustrates 
an example 
of two SBCsaccessing the dual-port memory of one SBC. 
Two important 
benefits are gained by using the dual- 


port architecture. 
First, in a multiple-processor 
system, if 


two processors 
communicate 
through 
shared 
memory, 
only one must access the memory using the system bus, 
and the amount of system bus traffic may be significantly 
reduced. Second, in a multiprocessor 
configuration 
where 
limited 
RAM storage 
is required, 
a 
separate 
memory 
board 
is not needed. 
Such small systems 
have all the 
required 
system bus-accessible 
memory on one or more 
of the SBCs. 


Intelligent 
Slave Architecture 


To distribute 
intelligence in larger systems, the intelligent 


slave concept 
was developed. 
An intelligent 
slave is a 


board that contains a CPU,some dedicated 
I/O capability, 


and a dual-port 
RAMfor interfacing 
to the system bus. 


For example, the iSBC544 
TY 
intelligent 
communications 
controller 
contains 
an 
8085A 
processor, 
four 
8251A 
serial 
I/O devices 
universal 
synchronous/asynchronous 


receiver/transmitters 
(USARTS),12 levels of priority 
in- 


terrupt, and 16k of dual-port RAM.All communication 
be- 


tween a master processor board, such as an iSBC86/12A 
TY 


board, 
and the 544 takes place using the 544 dual-port 


RAM (Fig 4). 
The 8085A processor 
does not have the 


capability 
of taking control of the system bus (becoming 


a bus master) 
and accessing other system resources. 


The 544 board 
was designed 
to operate 
using 
only 


onboard resources. The master SBCin the system transfers 
blocks of data and parameters 
to or from the 544 using 


the onboard 
dual-port 
RAM.To facilitate communication 
with the 544, an interrupt 
occurs 
when a master 
SBC 


writes into the lowest byte of memory 
of the dual-port 


RAM.The intelligent 
slav~ board 
can interrupt 
a master 
SBCby asserting 
one of the system bus interrupt 
lines 


with an I/O instruction. 
The address 
space occupied by 


the dual-port RAMmay be set anywhere within 1M bytes; 
20 address bits are decoded. 


Primary 
advantage 
of intelligent 
slave architecture 
is 


the ease with which multiprocessing 
applications 
may be 


implemented. The intelligent slave may be sent a buffer 
of data and commands 
with an interrupt 
occurring, 
via 


a write to the lowest byte of memory, as a start command. 
The master SBCmay continue operation 
with other func- 


tions to be notified, via an interrupt 
or a status byte in 


dual-port RAM,when the slave has completed a task. Since 
the intelligent slave may not access system resources via 
the system bus, no interference 
with the master SBCcan 
occur. 


F g 3 Dual-port memory archi· 
tecture. 
8086 
microprocessor 


on 86/12A 
uses dual-port con- 


troller to access onboard RAM. 
808SA on 80/05 
accesses 
this 


,same RAMacross system bus. 
Different configurations allow 
808SA access 
to part or all 


of dual port memory 


MULTIBUS 


ACCESSIBLE 


MULTIBU$ 
ACCESS 
BLOCKEO 


B ~L'-J ~J ~ I 


\. , " " 
c -ltl Y~,~I 
~\_I__ 
• 
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is oflen 
flexibility 
of 
system 
configuration. 
Using 
modu· 
larly 
configured 
systems, 
independent 
hardware 
and 
soft· 


ware 
modules 
are 
designed 
and 
implemented 
"ith 
indi- 


vidual 
processors 
or 
intelligent 
slave 
boards. 
When 
a 


particular 
configuration 
is required, 
the 
system 
desi~nler 


selects 
the 
necessary 
hardware 
and 
software 
modules 
and 


combines 
them 
with 
interprocessor 
communication 
soft· 


ware. 
Shortened 
system 
development 
time, 
simple 
debug. 


ging, 
and 
a convenient 
upgrade 
path 
for 
system 
expan· 


sion 
are 
the 
benefits 
of such 
a technique. 
High 
reliability. 
Multiprocessing 
may 
be 
used 
to 
isolate 


system 
tasks 
on 
individual 
processors 
in 
application" 
where 
a 
high 
degree 
of 
reliability 
is 
a 
requirement. 
If 
a processor 
fails, 
the 
remainder 
of 
the 
system 
continues 


to operate. 
Redundant 
designs, 
where 
a second 
processor 
may 
be 
dynamically 
assigned 
to 
perform 
the 
functions 
of a disabled 
processor, 
are 
a possibility. 


MultiprocessinC) 
With 
SinC)le-Board Computers 


The 
MULTtBUS architectural 
design 
facilitates 
multiproces· 


sing 
because 
multiple 
bus 
masters 
are 
accommodated, 
bus 
masters 
generate 
and 
acknowledge 
bus 
interrupts, 
and 
dual·port 
memory 
'and 
intelligent 
slave 
architecture 
can 
be implemented. 


Multiple Bus Masters 


A bus 
master 
is 
a dynamic 
board 
that 
takes 
control 
of 
the 
bus 
by 
asserting 
address 
and 
control 
lines. 
Only 
one 


bus 
master 
may 
control 
the 
bus 
at 
any 
given 
moment. 


Examples 
of 
bus 
masters 
include 
single· 
board 
computers 


Fig 
2 
P'ipeline 
and 
parallel 


partitioning, 
Single 
processor 


A performs 
tasks 
X, Y, and 
Z. 


Pipeline 
partitioning 
among 


three 
processors 
allows 
pro- 


cessor 
B 
to 
perform 
task 
X 


and 
pass 
resull 
to 
processor 


C; 
processor 
C 
to 
perform 


task 
Y 
and 
pass 
result 
to 


processor 
0; and 
processor 
D 


to 
perform 
task 
Z. 
Each 
pro- 


cessor 
except 
first 
must 
wait 


for 
input 
data 
generated 
as 


output 
from another 
processor. 


Parallel 
partitioning 
allows 


each 
processor 
to perform 
its 


task 
independently 


and 
direct 
memory 
access 
I flMA I 
controllers. 
A 
bus 


slave 
is a passive 
element 
011 the bus 
that 
does 
not 
assert 
address 
and 
control 
lines. 
Examples 
of bus 
slaves 
include 


memory 
or 
I () expansion 
hoards 
ano 
intelligent 
sIn, es. 
Several 
control 
lines 
exist 
on 
the 
bus 
so tbat 
potential 
bus 
masters 
can 
exchange 
control. 
These 
control 
lines. 


plus 
logic 
on 
the 
master 
boards, 
implement 
a 
priority 
scheme 
in 
\\hich 
the 
highest 
priority 
master 
requesting 


the 
bus 
obtains 
control. 
There 
are 
t\\O 
priority 
resolution 
scbemes 
for 
exchange 
of the 
bus, 
serial 
and 
parallel. 
l·s· 


ing: serial 
priority 
resolution, 
there 
may 
he 
up 
to 
three 


bus 
masters 
in 
the 
svstem: 
the 
parallel 
technique 
allows 


up 
to 16. A bus 
master 
i,. al\\ ays 
given 
the 
opportunity 


to complete 
a bus 
transaction 
before 
being 
preempted 
by 


a higher 
priority 
master. 
III acJdition, 
bus 
masters 
may 


retain 
control 
of 
the 
bus 
by 
"locking" 
the 
bus. 
The 
bus 


lock 
feature 
is 
required 
\\hell 
a 
master 
must 
have 
ex- 
clusive 
control 
of 
tbe 
bus 
for 
such 
functions 
as 
testin~ 
and 
setting' 
sofL\\are 
semu}Jhort:'s 
and 
('omlJletill~ 
opera- 


tions 
involving 
I/O devices. 
Since 
SHes 
ha\'e 
extensive 
onboard 
resource!"., 
system 


bus 
transactions 
are 
not 
required 
for 
all 
I/O and 
memory 


accesses. 
Depending: 
Oil the application 
and system 
desi~l1. 


multiple 
bus 
master 
systems 
with 
a 
small 
number 
of 


transactions 
can 
be 
configured. 
The 
system 
design 
goal 
is to use onboard 
resources 
\\henever 
possible. 
Frequently 
executed 
or 
time 
critical 
code 
should 
be 
stored 
in 
on· 
hoard 
memory 
to 
minimize 
system 
bus 
accesse!" 
ann 
to 


avoid 
delays 
while 
contending 
for 
the 
bus. 


Interprocessor 
Interrupts 


Ei/!:ht 
interrupt 
lines 
exist 
on 
the 
system 
bus. 
III addition 


to 
interrupts 
from 
1,0 
shl\e 
boards 
or 
I)~IA 
control1~r<. 


MULTIBUS 
OEVICE 


CASE 
MULTIBUS'M 
BHENI 
ACROI 
TRANSFER 
BYTE 
DATA 
PATH 
TRANSFERRED 


CO· 
DATO/- 
DAT71 
07 


A. 
H 
H 
8-BIT 
EVEN 
DATOf - DAT71 


Fig 5 
Three mechanisms 
for 
DO 
OATOI· 
DAHl 
byte and 
word transfers. 
All 
07 


byte 
transfers 
use 
DATO to 
B. 
H 
8-BIT 
000 
OAT? Only word transfers use 
CATOI- 
OAT?I 
high order bus lines OATS to 
DATF. Slash 
(I) after 
name 
indicates 
active 
low signal 


OATOI· 
DAHl 


16-81T 
EVEN 
C. 
H 
AND 
CATOI· 
OAlF' 
000 


OAT8I·OATFI 


systems 
include 
vibration 
analysis 
in mechanical 
struc- 


tures 
such as electric 
motors, 
automobiles, 
aircraft, 
and 


buildings, 
as well as speech, 
sonar, 
and 
low frequency 
radar 
analysis. 
])esilW objective 
is to monitor 
the condition 
of large 


electric 
motors. 
Po\\er 
spectra 
of vibration 
signals 
from 
various 
points 
on the motor 
are 
calculated 
in order 
to 


c1etect bearing 
wear and to predict 
an impending 
motor 


failure. 
Calculated 
power spectra 
are compared 
with ref- 


erence 
spectra, 
and, 
if thresholds 
in various 
regions 
of 


the speclra 
are exceeded, 
an operator 
alarm 
is activated. 
Information 
regarding 
the state 
of the 
motors 
and 
the 
reference 
spectra 
is stored 
on disc. 
The system mon itors 
16 challnels 
of analog 
input 
sig- 
nals 
generated 
by pairs 
of accelerometers 
mounted 
on 


each of eight 
motors. 
Sampling 
and calculations 
for the 
t\\ 0 channels 
of a single 
motor 
are 
performed 
simulta- 
neously: 
then the next molar 
in sequence 
is monitored. 
Vast Fourier 
transform 
(FFT) 
of a buffer 
of samples 
from 
all 
analog 
to 
digital 
converter 
(ADC) 
performs 
1)()I\l'r speclrum 
calculations. 
Real 
and 
imaginary 
paris 


of the 
FFT results are squared 
and summed to form a pow- 
er spectrum 
that is compared 
to the reference 
power spec- 


trum 
ill 
order 
to 
netermine 
jf 
the 
motor 
vibrations 
arc 


\\ ithin 
acceptahle 
tolerances. 
A 
CHT displays 
calculated 


and 
reference 
power 
spectra. 
At periodic 
intervals, 
data 
arc 
stored 
on disc 
for archiving 
the condition 
of each 


of the motors. 
If the motor 
spectra 
exceed the reference 


spectra, 
the un display 
and 
a control 
panel 
indicator 


alert the operator. 


System Hardware 


As shown in Fig 6, the 711 analog 
input board, 
contain- 


ing a 12-hit 
ADC, samples 
the 16 analog 
signals 
from the 


motors. 
The HO/OS processor 
hoard 
drives the 711 analog 


hoard 
and handles 
all system 
data 
acquisition 
activities. 


The BO/OS contains 
an HOHSACI'U, 
512 bytes of 
RAM, 
up 


to 4k hytes of EI'HOM/ROM, 
a timer/counter, 
parallel 
and 


serial 
I/O 
lines, and four levels of priority 
interrupt. 
The 


H6{12A hoard 
is the main 
system 
processor. 
The SOH6- 


hased board 
performs 
all the signal processing 
functions, 


displays 
the spectra 
on the 
CRT, drives the system control 
panel, and transfers 
motor condition 
data onto disc using 


the 20-1 single-density 
diskette 
controller. 


Increased 
system performance 
is the design motivation 


for using two processor 
boards. 
The H6 12A board, 
with 


its 5 
M IlZ 
HOH6 CPU, 
16-bit 
multiply/divide 
capability, 


64k bytes of dual-port 
RAM, and 32k bytes of EI>ROM/ROM, 


is used for the mathematically 
intensive 
power spectrum 


calculations. 


The ao 05 
processor 
board 
is used 
to offload 
data 


acquisition 
activities 
from the main 
proce~sor. 
It assumes 


all the overhead 
of handling 
the 711 analog 
board. 
Sam- 


pling is performed 
at 250-JLs intervals 
using the onboard 


timer; 
data 
from 
the two channels 
are 
scaled, 
demulti- 


plexed, and stored 
in a buffer. The S-bit processor 
board 


CONTROL 
PANEL 
I' ~ ~ 


was 
cho~en 
for 
this. function 
because 
it had 
the 
necessary 
onboard 
resources. 
yet 
was 
low 
in cost. 
Throughput 
per- 
formance 
improvements 
of 
up 
to 
40' I 
can 
be 
achie"ed 


using 
this 
2-processor 
approach. 


The 
no 05-711 
combination 
assumes 
the 
role 
of 
an 


intelligent 
analog 
subsystem, 
when 
viewed 
by the 
86 
12A 
processor. 
The 
86 
12A 
sends 
the 
no os commands 
,ia 


a parameter 
block, 
and 
the 
HO OS collects 
the 
data 
samples 


in 
buffers. 
When 
a buffer 
is complete, 
the 
80 
05 
signals 


the 
86 
12A 
using 
the 
parameter 
block. 
Thus, 
the 
80 
OS 


acts 
as 
an 
intelli/-!:ent 
DMA 
controller 
for 
the 
711 
board. 


Due 
to 
the 
lar/-!:e 
RAM 
requirements 
of 
the 
system_ 
the 


iSBC 300T'l 
Tt4.:\l expansion 
module 
is used 
to increase 
RA~I 


capacity 
to 
<»k 
bytes. 
}[emory 
has 
been 
configured 
to 


make 
16k 
bytes 
of memory 
accessible 
to 
the 
system 
bus, 


with 
the 
remainin/-!: 
48k 
bytes 
resen'ed 
for 
use 
by 
the 
onboard 
8086 
and 
not 
accessible 
to 
the 
system 
bus. 
The 
amount 
of 
n612A 
dual-port 
RA~I 
that 
is system 
bus 
ac- 


cessible 
may 
be 
configured 
in 
16k 
increments 
from 
zero 


I no 
memory 
accessible 
I to 64k 
Iall 
memory 
accessible 
I. 
The 
parameter 
block 
used 
for 
interprocessor 
communica- 
tion 
and 
a pair 
of 
buffers 
used 
for 
storage 
of 
the 
analog 


samples 
are 
stored 
in the memory 
accessible 
to the 
80 
05. 


Memory 
not 
accessible 
to the 
80 
05 contains 
the 
data 
and 
buffers 
used 
for 
the 
calculated 
averaged 
power 
spectra. 
reference 
spectra_ 
CRT 
displays, 
and 
disc 
data. 
The 
1(, 


bytes 
of 
the 
parameter 
block 
contain 
all 
information 
re- 


quired 
for 
communication 
between 
the 
tw.o 
SBCS 
in 
the 
system, 
including 
buffer 
addresses, 
status, 
size, 
sample 


rate, 
and 
start 
and 
end 
channel. 


Fig 
7 is a flow 
diagram 
illustrating 
how 
buffer 
status 
bytes 
are 
used 
to 
synchronize 
the 
fiiling 
and 
processing 


of 
the 
data 
buffers. 
Each 
buffer 
may 
be 
in 
one 
of 
two 


states, 
FULL 
or 
EMPTY. 
Initially, 
both 
buffers 
are 
EMPTY. 


At 
initialization, 
the 
80 
05 
fills 
buffer 
0, 
sets 
its 
status 


to 
FULL, 
fills 
buffer 
I, 
sets 
its 
status 
to 
FULL, 
and 
waits 


Fig 
6 
Data 
acquisition 
and 


signal 
analysis 
system. 
80/05 


drives 
711 
to 
handle 
all 
data 


acquisition 
functions 
while 86/ 


12A 
performs 
signal 
analysis, 


operator 
interfacing, 
data 
stor- 


age, 
and 
data 
retrieval 
func- 


tions 


for 
buffer 
0 to become 
B1PTY. 
It then 
fills 
buffer 
0, sets 


its 
slatus 
to 
FULL, 
waits 
for 
buffer 
1 to 
become 
EMPTY, 
etc. 
Initially, 
the 
86 
12A 
waits 
for 
buffer 
0 to 
be 
FULL, 


processes 
it, 
sets 
its 
status 
to 
EMPTY, 
waits 
for 
buffer 
1 


to 
be 
FULL. 
etc. 
l'sing 
this 
simple 
technique, 
the 
two 


processors 
synchronize 
each 
other 
\\ ith a minimal 
amount 


of o,·erhead. 
The 
parameter 
block 
approach 
is 
used 
to 
provide 
a 
simple 
means 
for 
interfacing 
the 
two 
SBCS. 
At 
system 
in- 


itialization, 
the gO 05 board 
needs 
only 
to know 
the 
base 
address 
of 
the 
paramete, 
block. 
Once 
this 
is known, 
,,11 


other 
information 
required 
for 
the 
gO OS to 
function 


tHopedy 
is 
a,·ailable. 
The 
end 
application 
and 
e,en 
the 


specific 
type 
of 
SBe 
that 
calls 
upon 
the 
no 
05 
for 
data 
~ampl('s 
remain 
irrelc,"anl 
to 
the 
gO '05. 
Dri,"er 
~oft\\are 


for 
the 
gO 
05 
is 
therefore 
highly 
modular 
and 
may 
be 


used 
in a variety 
of applications 
and 
configurations 
\\ith 


no changes required. 


A 
key 
capability 
of 
this 
system 
design 
is 
that 
the 


n6 
12,\ 
board 
does 
not 
use 
the 
system 
bus 
to access 
data 
samples, 
thus 
minimizing 
executioll 
time 
for 
the 
highly 


iterati\e 
FFT 
computation. 
The 
30 
OS 
processor 
takes 


the 
samples 
from 
the 
analog 
board 
and 
stores 
them 
di- 
rectly 
into 
the 
U6 
12A 
dual-port 
memory. 
Therefore, 
ex- 


cept 
for 
occasional 
disc 
transfers 
by 
the 
U6 
12A, 
the 


gO 05 
is 
the 
only 
processor 
USinl?: the 
system 
bus. 
This 


increases 
system 
throu~hput 
and 
eliminate~ 
contention 


for the system 
bus. 


Signal Processing Software 


The 
algorithm 
used 
for 
the 
HT 
in 
this 
application 
is 


kllo\\ n as "time 
decomposition 
\\ ith 
input 
bit 
reYersal.~'::! 


t-sing 
this 
algorithm_ 
an 
in-place 
FFT 
has 
been 
pro- 


~rammed 
for an input 
frame 
size of 128 complex 
points. 


Sixteen-bit 
integer 
mathematics 
is 
used 
for 
all 
internal 
calculations 
of the 
FFT. The 
H6 
12A 
board 
computes 
the 


128-point 
complex 
FFT 
in 
110 
ms. 
Computation 
of 
the 


a\eraged 
power 
spectra 
is performed 
using 
a double 
pre- 


WAIT 
FOR 
BUFFER 
F 
TO EMPTY 


SET 
STATUS 
OF 
BUFFER 
F = 
FULL 


WAIT 
FOR 
BUFFER 
P 
TO FILL 


SET STATUS 
OF 
BUFFER 
P = 
EMPTY 


Fig 7 
Synchronization ot two SBGs. Butter status bytes are used in sha~d 
parameter 
block. 
Simple semaphore mechanism is natural extension ot 
double buffered acquisition technique 


clslOn integer format. The 16·bit integer real and imagi. 
nary values which result from the FFT are squared 
and 


summed 
to obtain 
a 32·bit power spectrum. 
Thirty.two 


frames 
of data are processed and summed to form the 


averaged power spectrum. 


Two reasons for the slow growth of multiprocessing 
have 
been the limited selection of SHCsand the relatively small 
application 
base. These conditions 
are changing 
rapidly 
due to the large number 
of SHCSnow available. 
These 
boards 
contain 
dual.port 
RAM 
and newer 8· and 16·bit 
CPus, and provide system designers with a comprehensive 
set of tools 
for 
tackling 
applications 
that 
require 
the 
power of multiprocessing. 
Thus, the SHCapplication 
base 
has grown significantly in recent years. 


The system application 
combines a low cost 8-bit SBC 


and 
a high performance 
16·bit SHCin a configuration 
designed 
for both data acquisition 
and signal analysis. 


The 8·bit SHCrelieves the 16·bit SHCof all system data 
acquisition 
functions. 
Because the 16·bit board 
spends 


full time processing data, system throughput 
can be in· 


creased by as much as 401< . 
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New single-board 
computers 
sport dramatic 
advances in density and 
speed. The upshot: 
much more capable factory and office controllers. 


Enhanced 
j.LC boards strengthen 
factory and office controllers 


Designers of control and computer systems for the 
factory or office ShOllld be aware of the updated 
performance capabilities of the latest breed of single- 
board microcomputers. Faster microprocessors with 
wider word lengths are joining with denser, faster 
static memories to effect even finer control of time- 
critical operations. Yet the new crop maintains bus 
and software 
compatibility 
with 
earlier 
designs, 
needs 
fewer 
power 
supplies, 
and 
remarkably, 
charges no penalty for the extra work. In some cases, 
costs will dip. 
Using such boards as the iSBC 86/XX family, 
designers can trade in 8 bits for 16 (see "A Bridge 
from 8- to 16-bit Processing"), 5-MHz operation for 
8, older memory sockets for standard 28-pin JEDEC 
EPROM sockets. In addition, plug-on modules offer 
low-cost expansion. 
That 
adds up to double the 
EPROM capacity with no redesign and to quadruple 
the RAM capacity. 


Moreover, the iSBX 86/XX boards support the full 


IEEE-796 
Multibus 
specification-including 
16- 


Mbyte addressing features (send and receive) and the 
use of the lock feature 
(Fig. 1). Four additional 


address lines on the Multibus can be used to address 
memories larger than 1 Mbyte. The lock function 
increases system speed-by 
preventing arbitration 


delays-and 
serves in semaphore signaling applica- 


tions (for more particulars, 
see "Meet the Family"). 
In a multiprocessing system, individual processors 


must have a method of synchronization 
and mutual 


exclusion. 
A 
semaphore 
is 
the 
most 
common 


software 
method 
for 
providing 
these 
functions. 
Figure 2 shows an example of the semaphore concept 
and the need for dual locking. Assuming as in the 
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figure that the system consists of two processors and 
a disk-controller board, only one processor can access 
the mass-storage 
controller 
at any given time. A 


global mempry 
byte indicates 
whether 
the disk- 


controller board is in use-a 
1 indicates not busy; 


a 0, busy. 


When a request 
is made for a disk file, the 


requesting processor must check the global byte to 
determine whether the controller is busy. Although 
the process appears simple, there could be pitfalls 
(Fig. 3a). The hardware 
must allow the processors 


to read the semaphore bit without the intervening 
write cycle, to prevent deadlocking. 


Earlier 
boards needed global memory. not dllal 


porting, to support semaphores easily. They relied 
on Multibus arbitration 
to prevent deadlock, but that 


required 
an 
additional 
memory. 
Moreover, 
the 


boards required much more hardware and software 
to ensure proper operation. With the introducton of 
the IEEE-796 
Multibus 
specification, 
a lock line 


added to the system bus allows a much simpler 
implementation 
of 
semaphores 
in 
a 
dual-port 


memory (Fig. 3b). 
The on-board processor can prevent access to the 


dual port, and system accesses can lock the local 
processor out of the dual port. Both functions must 
be implemented 
to ensure 
the 
integrity 
of the 


semaphore 
byte. Figure 
4 shows the arbitration 


scheme for a dual port. 


Other board enhancements 
include Schmitt-trig- 


ger inputs on all critical Multibus command lines, 
which improves noise immunity. Pull-up resistors on 
all input lines allow for easy testing. The new board 
layouts minimize the length of the Multibus signal 
lines, reducing the line's susceptibility 
to crosstalk 


pickup. These improvements 
result in a mean time 


between failures (MTBF) that is 50% greater 
than 
that of comparable first-generation 
boards. 


Most measures of a computer ·board's processing 


power are summed up in one specification, the clock 


rate. With an 8-MHz 8086-2microprocessor on board, 
processing speeds up 60% over 5-MHz operation. 
Because of increased processing speed, on-board 


circuitry 
must be upgraded to handle higher data 
and instruction 
rates. Thus, some control functions 
are implemented 
with programmable 
logic arrays 


(PLAs). These high-speed devices not only replace 
dedicated chips, but also allow logic operations 
to 
be performed 
at clock rates exceeding 10 MHz. 


Stepping 
up the speed 


To accommodate 
the demand 
for greater 
data 
handling, RAM access time is 750ns, compared with 
1000 ns in earlier single-board computers. An addi- 
tional benefit of faster access time is the capacity 
for dual-port 
access. With this feature, 
dual-port 
RAMs can be accessed from the Multibus in 500 ns 
when locked and 800 ns when unlocked. High-speed, 
dual-port access permits interprocessor communica- 
tions to occur at a much faster 
rate. 
Since each iSBC board contains a different RAM 


storage capacity, speed performance is linked closely 
to a board's 
memory capacity. 
As Fig. 5 shows, 
numbers 
on the vertical scale indicate increasing 
performance 
for a given storage capacity. 
The timing/storage 
performance graphs of Fig. 5 
have been determined 
by making certain assump- 


tions about system operation. First, it is assumeJ 
that the system has no Multibus contention for the 


global memory as is the case in a single-master 
system. 
Also, all memory is accessed constantly, 


independent 
of on- or off-board optimization. 
For 


example, because of delays encountered in acquiring 
the Multibus, data rates plunge (in the iSBC 86/05) 
if more processors are added to a system. 


The expanded 
memory space-320 
kbytes-can 
serve either for enhanced multiprocessing 
or for the 


storage of large amounts of application code. The new 
design prevents 
performance-reducing 
arbitration 
delays in multiple-processor 
system operation. Pro- 


per partitioning 
of the system memory allows code 


accesses from 
the on-board 
memory. 
Since code 


fetching operations occupy most of the system-bus 
bandwidth, 
execution from local memory greatly 


accelerates 
system throughput. 


At home in factory 
or offic~ 


Two key application areas-and 
their diverse re- . 


quirements-stand 
out for single-board computers. 


One area 
includes 
machine 
and process control, 


instrumentation, 
and specialized data acquisition. 


Here, high-performance 
single-board computers are 


required to have extensive EPROM capacity to pro- 
vide sufficient program storage without relying on 
mass storage. 
The other area covers communications 
systems, 


small-business 
computers, 
and word and data pro- 


cessing. 
Single-board 
computers 
in office-of-the- 


I 
Numenc 
I 
I 
data 
I 
I 
processor 
I 
L 
..J 


future 
applications 
are generally 
RAM-intensive, 
with programs 
downloaded from a disk. A small 


amount of EPROM serves to bootstrap the system 
RAM at power-up. Mass storage is used to hold the 
large data bases required, but the computer board 
must support 
an I/O terminal 
for the human 
in- 


terface. Typically, word-processing systems require 
a high-performance 
CPU, a large RAM capacity, an 


interface for mass storage, a CRT terminal, 
and a 


printer. 


For RAM-intensive applications, a 128-kbyte RAM 


module fits on board. An on-board serial I/O port 
and 24 programmable I/O lines provide the interface 
with the CRT display and printer. With the inclusion 
of the iSBX bus on the board, low-cost I/O expansion 
is possible. Also, the iSBX 218 single- or double- 
density, 
single- or double-sided 
floppy-disk 
con- 
troller allows the entire system to fit on a single 
board. Moreover, even with those components on the 
board, there is room for a mathematics 
module. So 


the 
same 
basic 
system 
can 
8erve 
as 
a high- 


performance 
small-business 
computer. 
In 
high-speed 
communications 
applications, 
a 


high-end single-board controller outfitted 
with an 


iSBX module offers an interface capable of handling 
processing needs well into the future. Since the iSBX 
module communicates 
directly with the CPU over 


the iSBX bus, Multibus contention does not pose a 
problem. 
Another 
benefit 
of the bus-module 
ap- 


proach: reduced size and power consumption. 


Factory-control 
considerations 


When the single-board controller is to be used to 
control various phases of a manufacturing 
process, 
two things must be considered. First, operations are 
time-critical. 
The 
time 
between 
samples 
in 
a 
manufacturing 
process defines 
the maximum 
in- 


terval 
during 
which defective 
products 
could be 
made. Often, the volume of production requires the 
use of multiple processors. 
Second, factory operations 
do not occur at pre- 


determined intervals, but are event-driven. In addi- 
tion, code operations 
are usually fixed, since the 
factory environment is quite predictable. Thus, code 
can be stored in PROM or EPROM, but that requires 
enough ROM storage 
capability 
on the controller 


board. Finally, specialized operations are common, 
the most often used being floating-point arithmetic 
for three-dimensional 
movement and analog input 
and output 
for manipulating 
machinery. 


To equip a general-purpose 
board as a factory 
controller, 
its interrupt 
structure, 
PROM, and I/O 


access must all be high-speed, and the board must 
have a range of configurable options. After selecting 
a board, the designer should determine his maximum 
interrupt-speed 
requirement 
by 
measuring 
two 


2. Semaphore 
signaling 
is a method 
of 


synchronizing 
the operation 
of processors 
in a 


multiprocessing 
system. 
In an earlier 
single·board 
system 
(shown 
here), 
global 
storage 
prOVides the 
control 
signal 
for indicating 
the status 
of the disk 
controller-busy 
or not busy. 


Locked 


Processor 
request01 
Read 
Request Write busy 


1 
semaphore 
nOIbusy 
semaphore 
unlock 
Jl-LLr 


Processor 
Locked 
Read 
2 
request 
busy 
01 semaphore 


3. 
In newer 
single-board 
computers, 
a locking 
feature 


eliminates 
the need for global 
storage 
in semaphore 


signaling. 
Without 
locking, 
a deadlock 
can occur 
(a) when two 


processors 
try to access 
a system 
resource. 
The dual-port 


memory 
prevents 
such a problem 
(b). 


local 


"I 
I" 


System 
request 
request 


Arbiter 
local 
System 


grant 
grant 


(a) 


local 
request 


:1 
I: 


System 
request 


local 
lock 
ArbIter 
System 
lock 


Local gran! 
System 
grant 


(b) 


4. 
Adding 
dual-port 
memory 
locking 
to computer 
boards 


inhibits 
arbitration 
until the locked 
operation 
is completed 
(a). 


Earlier 
boards 
relied 
on global 
storage 
(b). 


things: the interrupt 
delay time, or the maximum 


time allowed from an interrupt 
request 
until the 
interrupt 
service routine instructions 
are executed, 
and the maximum number of interrupts 
that may 
need servicing in a given period. 
To compute interrupt 
delay, both hardware 
and 


software must be considered. For example, hardware 
on the board controls the processor's acknowledg- 
ment of the interrupt 
request. 
The board's 8086 


processor 
retrieves 
the address 
of the interrupt- 


service routine from the interrupt vector table, which 
is stored 
in an on-board RAM. Interrupt-service 


routines often store all registers on the stack before 
the servicing of an interrupting 
device begins. The 
total delay time is computed as follows: 


INT to 8259A to INTR at 8086 
INTA service time (16 8086 clocks) 
350 ns 
2000 ns 
(hardware) 
7000 ns 
(processor) 
12,875 ns 
(software) 


8086 INT vector computation 


(56 clocks) 


Storage of nine 8086 
registers 
(103 clocks) 


The' interrupt 
frequency depends on the interrupt 
delay time, the execution time of the interrupt- 
service routine, 
and the time to restore program 


execution. Time spent executing the service routine 
is highly device-dependent, 
but the return 
to pro- 


gram execution can be computed as follows: 


Retrieval 
of nine 8086 registers 


(90 clocks) 
Interrupt 
return of 8086 (30 clocks) 


11,250 ns 
(software) 
3750 ns 
(processor) 
500 ns 
(hardware) 


Code fetch of next instruction 


(four clocks) 


Interupt 
frequencies for the iSBC 86/14-assum- 


ing several 
I/O 
service routines-are 
24,600 per 
second for sending a character 
to a CRT, 24,600/s 


for receiving a character from the CRT, and 22,000/s 
for clock interrupts. 
The access times of current EPROMs range from 


200 to 1000 ns. For slower devices, wait states (an 
integer number of processor clock times) are added 
to the access time. At an 8-MHz processing frequen- 
cy, a 200-ns EPROM operates with zero wait states. 
The most critical 
time, access time from a chip 


86/12A 
86/05 
B6/XX 


Ram reqUirements 
from 


16 kbytes 
to 64 kbytes 


17 


13 


10 


86/12A 
86105 
86/14 


RAM 
requirements 
greater than 64 kbytes 


19 


15 


1.0 


86/12A 
86/05 
86/30 


5. 
The random-access-memory 
performance 
of single-board 


computers 
is related 
to the amount 
of storage 
a board 


provides. 
The latest 
boards 
are designed 
to work 
most 


efficiently 
with storage 
capacities 
of 16to 256 kbytes. 


6. 
Factory 
controllers 
execute 
most of the system 
code from 
EPROMs. 
With a high-speed 


EPROM, 
valid data appears 
on the Multibus 
about 
300 ns after valid 
addresses 
are applied. 


enable, 
is 200 ns. The timing 
relationships 
for access- 
ing an 
EPROM 
are 
shown 
in Fig. 
6. 


From 
a system 
standpoint, 
all peripheral 
compo- 
nents 
can 
be 
accessed 
in 
about 
300 
ns 
after 
a 


command. 
At a clock rate 
of 5 MHz, that 
forces 
one 
wait 
state; 
at 8 MHz, two wait 
states. 
A variety 
of 


devices 
interfaces 
with 
the 
iSBX 
bus, 
permitting 
custom 
configurations 
of a single-board 
controller 


for factory 
applications. 
Two 
analog 
modules, 
one 
for input 
and one for output, 
can monitor 
or control 


plant 
equipment. 
For expansion 
of digital 
inputs 
or 


ISBC86IJO 
Winchester 
with 128-kbyte 
controller 
RAM 
wIth Iloppy-disk 
Multlmodule 
board 
.sex board 


I 
I 


7. Considerable 
hardware 
can be saved 
when 
a single-board 


computer 
replaces 
earlier 
versions 
(8) in an office 
controller. 
One advantage of the new boards (b) is their large on-board 
storage capacity, which allows code to be stored locally, 
Increasing system speed and throughput. 


outputs, 
a parallel 
I/O 
module 
can 
be added. 


Whereas 
interrupt 
response 
time 
is 
a 
critical 


parameter 
in 
a factory 
environment, 
other 
con- 


siderations 
become 
critical 
in an office environment. 


One of those 
is throughput, 
the 
number 
of tasks 
a 
worker 
can perform. 
As a result, 
office 
controllers 


must 
provide 
the 
user 
with 
fast 
response 
time. 
In 
addition, 
since 
office 
controllers 
usually 
perform 
a 
wide variety 
of tasks, 
execution 
is mainly 
from RAM, 


not 
ROM. 
Moreover, 
because 
most 
tasks 
are 


dynamic, 
large 
mass-storage 
devices 
are 
needed. 


Programs 
are 
loaded 
from 
mass 
storage 
into 
the 


processor's 
memory 
and executed. 
In addition, 
most 


programs 
are 
in a high-level 
language 
(for 
word 
processing 
and 
other 
office 
tasks), 
which 
requires 
considerable 
hardware 
and 
software 
support. 


As with factory 
controllers, 
configurable 
systems 


are important 
in the office environment, 
since special 
applications 
will require 
additional 
hardware. 
Word 
processors, 
for example, 
are generally 
linked 
via a 
serial 
communications 
line to a central 
processor, 
or 


mass-storage 
device, 'and 
the 
link 
must 
be a high- 
speed 
one 
to minimize 
response 
time. 


To 
meet 
office 
system 
requirements, 
computer 
boards 
should 
have the following 
features: 
an operat- 
ing system 
having 
a human 
interface 
(keyboard), 
a 


program 
loader 
and configurable 
peripheral 
support 
for 
mass 
storage, 
communications 
controllers 
and 


high-level 
languages; 
a maximum-size 
RAM 
with 


minimum 
access-time 
devices 
for program 
support; 


Until recently, 
most dedicated 
controller 
applica- 


tions had to be handled with an 8-bit microcomputer 
because of price and performance 
considerations. 
But 
with performance 
and software 
needs on the rise, 
designers are faced with moving up to 16-bit devices 
to obtain the necessary computing 
power. When the 
move up happens, 
however, hardware 
and software 
compatibility 
considerations 
often get the short end 
of the stick. 
The iSBC 88/25 could be termed the missing link 


between 
8-bit 
buses 
and 
16-bit processing 
power. 


Using the 8088 microprocessor, 
the board i'nterfaces 
with the outside world on an 8-bit bus, but internally 
it operates 
as a 16-bit system. 
Since software 
com- 
pilers such as the PLlM-86 often generate 16-bit data- 
access instructions, 
a designer 
using a 16-bit 8086- 
based board must have a 16-bit memory expansion 
board or pay a burdensome 
software penalty. What's 
more, an 8086-based board must access instructions 
in 16-bit words, eliminating 
the possibility 
of using 


8-bit boards for instruction 
storage. 


The iSBC 88/25 automatically 
breaks 
all 16-bit 
words into 8-bit bytes on the Multibus. 
Therefore, 
independently 
of software, the hardware 
converts all 
accesses to 8-bit bytes transparently 
to the user. This 


gives the board the dual advantage 
of being fully 


compatible with all 8-bit hardware 
devices and 16-bit 
software. 
To retain 
compatibility 
with Intel 
stan- 


dards, 
the board 
is designed to interface 
with the 


Multibus system bus, the iSBX bus, memory modules, 
and the iSBC 337 math 
module and numeric 
data 


processor. The board also contains JEDEC-compatible 
28-pin sockets 
to accommodate 
EPROM and static' 


byte-wide 
RAM. 
The 8088 microprocessor is being used in the second 


generation 
of personal 
computers, 
such as the one 


from 
IBM. 
Several 
other 
personal-computer 
and 
small-business 
systems 
will also use the 8088. With 
its software compatibility 
with the 8086 processor and 
widespread 
application 
in personal 
and small-busi- 
ness systems, the software repertoire 
of the 8088 will 


exceed that 
of any microprocessor. 


ana 
naraware 
support 
lor 
ootn 
mass 
stora!{e 
and 
communications. 
Office controllers 
call for lots of RAM, and a board 
with 
a capacity 
of up to 256 kbytes 
is suitable. 
A 
dynamic 
RAM 
controller 
handles 
the 
automatic 
refreshing 
and generates 
the proper 
timing 
for the 


row and cOlumn 
addresses. 
t'LA 
devIces 
send com- 
mands 
to the controller 
to initiate 
the RAM access. 


The differences 
between 
early 
and updated 
office 


controllers 
are shown 
in Fig. 7. Additional 
memory 


expansion 
on 
the 
Multibus 
is 
necessary 
to 
meet 
system 
requirements. 
The 
f1oppy-<lisk 
controller 


Progress in semiconductor 
den- 
sity 
and 
speed 
translates 
into 
more 
functions 
and 
greater 
throughput 
in the latest breed of 


single-board 
computers. 
Another, 
more 
subtle, 
benefit 
accrues: 


board-level 
controllers 
can 
be 
made to fit within a wide range of 
performance 
and cost slots, result- 


ing in greater 
freedom of design 
choice. 


Thus 
whereas 
one board, 
the 
iSBC 86/05, provides high-speed, 
low-cost compatibility 
with earlier 
units, two other boards, the iSBC 
86/14 and iSBC 86/30, drop into 
the 
high-performance 
end 
of 


system 
integration. 
Both 
con- 


troller 
boards 
are 
memory-in- 
tensive: 
the 
former 
is available 
with 32 kbytes of RAM, expand- 
able to 64 kbytes; the latter starts 
with 128 kbytes of RAM and can 
be expanded to 256 kbytes. Large 
storage capacity 
is backed up by 


8-MHz processing rates and iSBX- 
bus support. 


Since all 16-bit single-board con- 
trollers 
are software-compatible, 
both present and future controller 
systems 
can 
be upgraded 
with 
minimal 
extra 
investment. 
Once 
established 
and 
proven 
in prior 
designs, 
bus and software 
stan- 
dards reduce hardware conversion 
costs. 
Since iSBC 86/XX boards con- 


stitute 
a family, 
hardware 
and 


software 
are 
interchangeable 


throughout. 
For 
example, 
the 


earlier iSBC 86/12A is compatible 
with 
the 
ICE 86, the 
in-circuit 


emulator for debugging hardware 
and software, 
and with the iSBC 


337, 
the 
multimodule 
numeric 


data 
processor 
for 
high-speed 


mathematics. 


For 
external 
interfacing, 
the 
86/12A offers three connections: a 
serial port, a parallel port, and the 
Multibus interface. 
All these con- 
nections are available with at least 
the same user options. Since the 
connector pinouts 
stay the same, 


all 
single-board 
controllers 
are 


plug-compatible. 


board 
alone 
must 
be implemented 
with 
a full 
size 
Multibus 
board. 
Using newer boards 
not only reduces 
system 
size, 
but 
also 
improves 
performance. 
The 


large 
on-board 
memory 
stores 
enough 
program 
in- 
formation 
to allow operation 
that is 100% faster 
than 
first-generation 
boards. 0 


The iRMX 86 operating 
system 


standard, 
together 
with 
its ap- 
plication 
software, 
dictates 
that 


all single-board 
controllers 
have 


the same memory-access capabili- 
ty and I/O resources. 
To ensure 


compatibility 
between the earlier 


and the 
newer 
boards, 
the new 
iSBC 86/14 is designed with the 
same memory capabilities 
as the 


iSBC 86/12A for on- and off-board 
access to memory. In addition, the 
iSBC ~6/30, with its 128 kbytes of 
RAM, 
further 
extends 
the 


system's 
capabilities. 
I/O 
con- 


trollers 
are 
contained 
on 
iSBC 


86/XX boards in the same default 
configuration 
as on iSBC 86/12A 


boards. Thus, 
the software-like 


the 
hardware-is 
plug-compati-. 
ble, virtually eliminating 
the need 
for 
additional 
software 
expense 
when upgrading 
a system. 
If a system's RAM requirements 
are under 16kbytes, an iSBC 86/05 
supported by a high-speed 8-kbyte 
RAM Multimodule 
board 
(iSBC 
302), offers 
better 
performance 
than 
either 
an 
86/12A 
or any 
newer board. For factory applica- 
tions, the 86/05 offers twice the 
EPROM capacity of the 86/14 or 
30 board. 
But as RAM require- 
ments 
grow past 
16 kbytes, 
the 
86/05 
becomes 
less 
desirable 
because the additional memory re- 
quired must be accessed from the 
Multibus. Data accesses from the 


bus occur at a much slower rate 
than 
those 
from 
the 
on-board 


memory. 
For midrange 
RAM storage ap- 


plications-16 
to 64 kbytes-there 


is the iSBC 86/14 and a 32-kbyte 
RAM Multimodule 
board 
(iSBC 


300A). The 86/30 runs as fast as 
the 86/14, but for RAM require- 
ments 
exceeding 
64 kbytes, 
the 


86/30 continues 
to access its in- 


ternal 
memory, 
providing 
faster 


operation. 
Moreover, an expanded 


memory 
space-a 
total 
of 
320 


kbytes consisting of 256 kbytes of 
RAM and 64 kbytes of EPROM- 
make the 86/30 the performance 
leader 
in large 
system 
applica- 


tions. 
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Boards 


intel~ 
iSBCTM337 
MULTIMODULETM NUMERIC 
DATA PROCESSOR 


• High speed fixed and floating point 
functions for ISBC 86, 88 and IAPX 86, 
88 systems 


• MULTIMODULE option containing 8087 
Numeric Data Processor 


• Supports seven data types Including 
single and double precision Integer and 
floating point 


• Implements proposed IEEE Floating 
Point Standard for high accuracy 


• Extends host CPU Instruction set with 


arithmetic, logarithmic, transcendental 
and trigonometric Instructions 


• 50 x performance Improvements In 


Whetstone benchmarks over IAPX86110 
performance 


• Software support through ASM·86188 


Assembly Language and High Level 
Languages 


The Intel 
iSBC 337 MUL TIMODULE 
Numeric 
Data Processor 
offers 
high performance 
numerics 
support 


for iSBC 86 and iSBC 88 Single 
Board Computer 
users, for applications 
including 
simulation, 
instrument 


automation, 
graphics, 
signal 
processing 
and business 
systems. 
The coprocessor 
interface 
between 
the 


8087 and the host CPU provides 
a simple 
means of extending 
the instruction 
set with over 60 additional 


numeric 
instructions 
supporting 
six additional 
data types. 
The data formats 
conform 
to the proposed 


IEEE Floating 
Point 
Standard 
insuring 
highly 
accurate 
results. 
The 
MULTIMODULE 
implementation 


allows 
the iSBC 337 module 
to be used on all iSBC 86 and iSES88 
Microcomputers 
and can be added as 


an option 
to custom 
iAPX 86 and iAPX 88 board designs. 


the 
following 
are trademarks 
of Intel Corporation 
and may 
be used 
only 
to descnbe 
Intet products: 
Index, 
Intel, 
MULTIBUS, 
RMX, 
iRMX, 
UPI, ICE, iSBC, 
iSaX, 
MULTI MODULE, 


IAPX and ieS. 
intel 
C')rporalion 
assumes 
no responsibility 
lor the use of any circuitry 
other 
than circuitry 
embodied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are 


implied. 


The iSBC 337 MULTIMODULE Numeric Data Pro- 
cessor provides arithmetic and logical instruction 
extensions to the 8086 and 8088 CPU's of the 
iAPX 86 
and 
iAPX 88 
families, 
to 
provide 


iAPX 86/20 and iAPX 88/20 Numeric Data Proces- 
sors. The instruction set consists of arithmetic, 
transcendental, 
logical, 
trigonometric 
and ex- 


ponential instructions 
which can all operate on 


seven different data types. The data types are 16, 
32, and 64 bit integer, 32 and 64 bit floating point, 
18 digit packed BCD and 80 bit temporary. 


Coprocessor Interface 


The coprocessor interface between the host CPU 
(8086and 8088)and the iSBC 337 processor pro- 
vides easy to use and high performance math pro- 
cessing. Installation of the iSBC 337 processor is 
simply a matter of removing the host CPUfrom its 


host's CPU socket, and reinstalling the host CPU 
chip into the socket provided for it on the iSBC 
337 processor (see Figure 1). All synchronization 
and timing 
signals 
are provided via the 
co- 


processor interface with the host CPU. The two 
processors also share a common address/data 
bus. (See Figure 2.) The 8087 Numeric Data Pro- 
cessor (NDP) component is capable of recogniz- 
ing and executing 8087 numeric instructions as 
they are fetched by the host CPU. This interface 
allows concurrent processing by the host CPU 
and the 8087.It also allows 8087and host CPU in- 
structions to be intermixed in any fashion to pro- 
vide the maximum overlapped operation and the 
highest aggregate performance. 


High Performance and Accuracy 


The 80-bit wide internal registers and data paths 
contribute significantly to high performance and 


minimizes the execution time difference between 
single and double precision 
floating 
point for- 


mats. This 80-bit architecture, in conjunction with 
the use of the proposed IEEE Floating Point Stan- 
dard provides very high resolution and accuracy. 
This precision is complemented by extensive ex- 
ception 
detection 
and 
handling. 
Six 
different 
types of exceptions can be reported and handled 
by the 8087. The user also has control over inter- 
nal precision, infinity control and rounding con- 
trol. 


As a coprocessor to an 8086 or 8088, the 8087 is 
wired in parallel with the CPU as shown in Figure 
2. The CPU's status and queue status lines enable 
the NDP to monitor and decode instructions 
in 
synchronization 
with the CPU and without 
any 


CPUoverhead. Once started, the 8087can process 
in parallel with and independent of the host CPU. 
For resynchronization, the NDP's BUSY signal in- 
forms the CPU that the NDP is executing an in- 
struction and the CPU WAIT instruction tests this 
signal to insure that the NDP is ready to execute 
subsequent instructions. 
The NDP can interrupt 


the CPUwhen it detects an error or exception. The 
interrupt request line is routed to the CPUthrough 
an 8259A Programmable Interrupt Controller. This 
interrupt request signal is brought down from the 
iSBC 337 module to the iSBC 86, 88 Single Board 
Computer through a single pin connector 
(see 


Figure 1).The signal is then routed to the interrupt 
matrix for jumper connection to the 8259A Inter- 
rupt Controller. Other iAPX 86 and 88 designs may 
use a similar arrangement, or by masking off the 
8086's "READ" pin from the iSBC 337 socket, pro- 
visions are made to allow the now vacated pin of 
the host's CPU socket to be used to bring down 
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I Isac 337 
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ERROR 
OR EXCEP 


I 
I 
INTERRUPT 


Data 
Precl· 
Most 
Significant 
Byte 


Formats 
Range 
sian 
7 
07 
07 
07 
07 
07 
07 
07 
07 
07 
0 


Word Integer 
10" 
16 Bits 
1'5 
10I 
Two's Complement 


Short Integer 
109 
32 Bits 
131 
101 
Two's Complement 


10'9 
64 Bits 
163 
101 
Two's 
Long Integer 
Complement 


Packed BCD 
10'8 
18 Digits 
sl 
- 
1017 
0,61 
10, 
oJ 


Short Real 
10%38 
24 Bits 
slE7 
EJF, 
F231 
Folmplicit 


Long Real 
10%308 53 Bits 
slEw 
EoIF, 
F521 
Folmplicit 


Temporary Real 
10%4932 64 Bits 
S IE'4 
EoIFo 
, 
F631 


Note: 


Integer: I 
Fraction: F 
Exponent: E 


Sign:S 
BCD Digit (4 Bits): D 
Bias= 127for Short Real 


1023for Long Real 
16i383for Temp Real 


the 
interrupt 
request 
signal 
for connection 
to the 


base 
board 
and then 
to the 
8259A. 
Another 
alter- 
native 
is to use 
a wire 
to establish 
this 
connec- 


tion. 


Table 
1 lists 
the 
seven 
data 
types 
the 
8087 sup- 
ports 
and 
presents 
the 
format 
for 
each 
type. 


Internally, 
the 8087 holds 
all numbers 
in the tem· 
porary 
real 
format. 
Load 
and 
store 
instructions 


automatically 
convert 
operands 
represented 
in 


memory 
as 16,,32-, 
or 64-bit 
integers, 
32· or 64-bit 


floating 
point 
numbers 
or 
18-digit 
packed 
BCD 


numbers 
into 
temporary 
real 
format 
and 
vice 


versa. 


Computations 
in 
the 
8087 
use 
the 
processor's 


register 
stack. 
These 
eight 
80·bit 
registers 
provide 


the equivalent 
capacity 
of 40 16-bit 
registers. 
The 


8087 register 
set can be accessed 
as a staCk, with 


instructions 
operating 
on the 
top 
stack 
element, 
or as a fixed 
register 
set, with 
instructions 
operat- 
ing on explicitly 
designated 
registers. 


Table 
3 lists 
the 8087's 
instructions 
by class. 
As- 
sembly 
language 
programs 
are 
written 
in 
ASM 


86/88, the IAPX 86, 88 assembly 
language. 
Table 
2 


gives the execution 
times 
of some typical 
numeric 


instructions 
and their 
equivalent 
time 
on a 5 MHz 


8086. 


Table 2. Execution 
Time 
for Selected 
8087 Actual 


and Emulated 
Instructions 


Approximate 
Execution 


Floating 
Point Instruction 
Time (microseconds) 


8087 
8086 
(5 MHz Clock) 
Emulation 


Add/Subtract Magnitude 
14/18 
1,600 


Multiply (single precision) 
19 
1,600 


Multiply (extended precision) 
27 
2,100 


Divide 
39 
3,200 
Compare 
9 
1,300 


Load (double precision) 
10 
1,700 


Store (double precision) 
21 
1,200 


Square Root 
36 
19,600 


Tangent 
90 
13,000 


Exponentiation 
100 
17.100 


The 
NDP is internally 
divided 
into 
two 
processing 


elements, 
the control 
unit (CU) and the numeric 
ex- 


ecution 
unit (NEU), providing 
concurrent 
operation 


of the two 
units. 
The NEU executes 
all numeric 
in- 


structions, 
while 
the CU receives 
and decodes 
in- 


structions, 
reads and writes 
memory 
operands 
and 


executes 
processor 
control 
instructions. 


Control Unit 


The CU keeps 
the 8087 operating 
in synchroniza- 


tion 
with 
its host 
CPU. 8087 instructions 
are inter· 


mixed 
with 
CPU 
instructions 
in a single 
instruc- 


Addition 


FADD 
Add 
real 
FADDP 
Add real and pop 
FIADD 
Integer add 


Subtraction 


FSUB 
Subtract real 
FSUBP 
Subtract real and pop 
FISUB 
Integer subtract 
FSUBR 
Subtract real reversed 
FSUBRP 
Subtract real reversed and pop 
FISUBR 
Integer subtract reversed 


MultiplicatiOn 


FMUL 
Multiply 
real 
FMULP 
Multiply real and pop 
FIMUL 
Integer multiply 


Division 


FDIV 
Divide 
real 
FDIVP 
Divide-real and pop 
FIDIV 
Integer divide 
FDIVR 
Divide real reversed 
FDIVRP 
Divide real rever.sedand pop 
FIDIVR 
Integer divide reversed 


Other 
Operations 


FSQRT 
Square root 
FSCALE 
Scale 
FPREM 
Partial reminder 
FRNDINT 
Round to integer 
FXTRACT 
Extract exponent and significand 
FABS 
Absolute value 
FCHS 
Change sign 


Real Transfers 


FLD 
Load real 


FST 
Store feal 


FSTP 
Store 
real 
and 
pop 


FXCH 
Exchange registers 


Integer Transfers 


FILD 
Integer load 


FIST 
Integer store 
FISTP 
Integer store and pop 


Packed Decimal Transfers 


FBLD 
Packed 
decimal 
(BCD) 
load 


FBSTP 
Packed decimal (BCD) store and pop 


FCOM 
FCOMP 
FCOMPP 
FICOM 
FICOMP 
FTST 
FXAM 


Compare real 
Compare real and pop 
Compare real and pop twice 
Integer compare 
Integer compare and pop 
Test 
Examine 


FPTAN 
FPATAN 
F2XMl 
FYl2X 
FYl2XPl 


Partial tangent 
Partial arctangent 
2);·1 
Yolog,x 
Y.log2(X + 1) 


tion stream. The CPU fetches 
all instructions 
from 
memory; 
by monitoring 
the status 
signals 
emitted 
by the 
CPU, 
the 
NDP 
control 
unit 
determines 
when an 8086 instruction 
is being fetched. 
The CU 


taps the bus in parallel 
with the CPU and obtains 


that portion 
of the data stream. 


After decoding 
the instruction, 
the host executes all 
opcodes 
but 
ESCAPE 
(ESC), while 
the 
8087 ex- 
ecutes 
only 
the 
ESCAPE class 
instructions. 
(The 
first five bits of all ESCAPE instructions 
are identi- 
cal). The CPU does provide addressing 
for ESC in- 
structions, 
however. 


An 8087 instruction 
either will not reference 
mem- 
ory, will require loading one or more operands from 
memory 
into the 8087, or will require storing 
one or 
more operands 
from the 8087 into memory. 
In the 
first case a non-memory 
reference 
escape 
is used 
to start 8087 operation. 
In the last two cases, the 
CU makes use of a "dummy 
read" cycle initiated 
by 
the CPU, in which 
the CPU calculates 
the operand 
address and initiates 
a bus cycle, but does not cap- 
ture the data. Instead, the CPU captures 
and saves 
the address which the CPU places on the bus. If the 


F1NITfFNINIT 
Initialize processor 


FDISI/FNDISI 
Disable interrupts 


FENI/FNENI 
Enable interrupts 


FLDCW 
Load control word 


FSTCW/FNSTCW 
Store control word 


FSTSW/FNSTSW 
Store status word 


FCLEXlFNCLEX 
Clear exceptions 


FSTENV/FNSTENV Store environment 


FLDENV 


FSAVElFNSAVE 


FRSTOR 


FINCSTP 


FDECSTP 


FFREE 


FNOP 


FWAIT 


Load environment 


Save state 


Restore state 


Increment stack pointer 


Decrement stack pointer 


Free register 


No operation 


CPU wait 


instruction 
is a load, the CU additionally 
captures 


the data word 
when 
it becomes 
available 
on the 


local data bus. If data required 
is longer 
than one 


word, the CU immediately 
obtains 
the bus from the 


CPU using the request/grant 
protocol 
and reads the 


rest of the information 
in consecutive 
bus cycles. 


In a store operation, 
the CU captures 
and saves the 


store 
address 
as in a load, and ignores 
the data 


word 
that 
follows 
in 
the 
"dummy 
read" 
cycle. 


When the 8087 is ready to perform the store, the CU 
obtains 
the 
bus 
from 
the 
CPU 
and 
writes 
the 


operand 
starting 
at the specified 
address. 


Numeric Execution Unit 


The NEU executes 
all instructions 
that involve the 


register 
stack; 
these 
include 
arithmetic, 
logical, 


transcendental, 
constant 
and 
data 
transfer 


instructions. 
The data path in the NEU is 80 bits 


wide (64 fraction 
bits, 15 exponent 
bits and a sign 


bit) which 
allows 
internal 
operand 
transfers 
to be 


performed 
at very high speeds. 


When the NEU begins 
executing 
an instruction, 
it 


activates 
the 
8087 
BUSY 
signal. 
This 
signal 
is 


used 
in conjunction 
with 
the CPU WAIT 
instruc· 


tion 
to resynchronize 
both 
processors 
when 
the 


NEU has completed 
its current 
instruction. 


Register Set 


The 8087 register 
set is shown 
in Figure 3. Each of 


the eight data registers 
in the 8087's register 
stack 


is 80 bits 
wide 
and is divided 
into 
"fields" 
corre· 


sponding 
to the NDP's temporary 
real data type. 


The register 
set may be addressed 
as a push down 


stack, through 
a top of stack pointer or any register 


may be addressed 
explicitly 
relative 
to the top of 


stack. 


Status Word 


The status word shown in Figure 4 reflects 
the over· 


all state of the 8087; it may be stored in memory and 
then inspected 
by CPU code. The status 
word is a 


16·bit register divided into fields as shown in Figure 
4. The busy bit (bit 15) indicates 
whether 
the NEU is 


executing 
an instruction 
(B = 1) or is idle 
(B = 0). 


Several instructions 
which store and manipulate 
the 


status word are executed 
exclusively 
by the CU, and 


these do not set the busy bit themselves. 


The four 
numeric 
condition 
code 
bits 
(Co-C:J are 


similar to the flags in a CPU: various instructions 
up- 


date these bits to reflect the outcome 
of NDP opera- 
tions. 


Bits 
14·12 of the 
status 
word 
point 
to the 
8087 


register 
that 
is the current 
top·of·stack 
(TOP). 


Bit 7 is the interrupt 
request 
bit. This 
bit is set if 


any 
unmasked 
exception 
bit 
is set and 
cleared 


otherwise. 


Bits 5-0 are set to indicate 
that the NEU has detect- 


ed an exception 
while executing 
an instruction. 


The tag word 
marks 
the content 
of each register 


as shown in Figure 5. The principal 
function 
of the 


tag word 
is to optimize 
the 
NDP's 
performance. 


The tag word 
can be used, 
however, 
to interpret 
the contents 
of 8087 registers. 


III IR is set if any unmasked 
.xception 
bit is set, ct.-red 
otherwise. 


121Top Values: 


000:::1: 
Register 
0 is Top of Stack. 
001 = Register 
1 is Top 01 Stack. 
··· 
111 = Register 
7 is Top of Stack. 


INVALID 
OPERATION 


DENORMALIZEO 
OPERAND 


ZERO 
DIVIDE 


OVERFLOW 


UNDERFLOW 


PRECISION 


(RESERVED) 


INTERRUPT 
REQUEST 
III 


CONDITION 
CODE 


TOP 
OF STACK 
POINTER 
(2) 


NEU 
BUSY 


intel 


TAG 
VALUES: 


00 = VALID 
01 = ZERO 
10 = SPECIAL 
11 = EMPTY 


Figure 5. 8087 Tag Word 


Instruction and Data Pointers 


The instruction 
and data 
pointers 
(see Figure 
6) 
are 
provided 
for 
user-written 
error· 
handlers. 
Whenever 
the 8087 executes 
an NEU instruction, 


the CU saves the instruction 
address, 
the operand 
address 
(if present) 
and the 
instruction 
opcode. 


The 8087 can then store this data in memory. 


INSTRUCTION 
POINTER 
(15-0) 


INSTRUCTION 
POINTER I 0 I 
INSTRUCTION 
OPCOOE 
(10·0) 


(19·16) 


DATA 
POINTER 
(15·0) 


DATA 
POINTER 
(19-16) I 
0 


Control Word 


The NDP provides several processing 
options which 
are selected 
by loading 
a word from 
memory 
into 
the control 
word. Figure 7 shows the format and en- 
coding 
of the fields 
in the control 
word. 


Exception Handling 


The 8087 detects 
six different 
exception 
conditions 


that can occur during 
instruction 
execution. 
Any or 


all exceptions 
will cause an interrupt 
if unmasked 


and interrupts 
are enabled. 


If interrupts 
are disabled 
the 8087 will simply 
sus- 


pend execution 
until the host clears the exception. 


If a specific 
exception 
class is masked and that ex- 


ception 
occurs, 
however, the 8087 will post the ex- 


ception in the status register and perform an on-chip 
default 
exception 
handling 
procedure, 
thereby 


allowing 
processing 
to continue. 
The exceptions 


that the 8087 detects 
are the following: 


1. INVALID 
OPERATION: 
Stack 
overflow, 
stack 


underflow, 
indeterminate 
form 
(010, 
-, 
etc.) 


or 
the 
use 
of 
a 
Non-Number 
(NAN) 
as 
an 


operand. An exponent 
value is reserved and any 


bit pattern 
with this value in the exponent 
field 


is termed a Non-Number 
and causes this excep- 


tion. 
If this 
exception 
is masked, 
the 
8087's 


default 
response 
is to generate 
a specific 
NAN 


called 
INDEFINITE, 
or to propagate 
already 
ex- 


isting 
NANs as the calculation 
result. 


2. OVERFLOW: 
The 
result 
is 
too 
large 
in 


magnitude 
to fit the specified 
format. 
The 8087 


will generate 
the code for infinity 
if this excep- 


tion 
is masked. 


/II Precision 
Control 


00 = 24 bits 
01 = Reserved 
10 =53 
bits 


11 =64 
bits 


III Rounding 
Control 


00 = Round 
to Nearest 
or Even 
01 = Round Down (toward· 
) 
10 = Round 
Up (toward 
+ ) 
11 = Chop 
(truncate 
toward 
zero) 


INVALID 
OPERATION 


DENORMALIZEO 
OPERAND 


ZERO 
DIVIDE 


OVERFLOW 


UNDERFLOW 


PRECISION 


(RESERVED) 


INTERRUPT 
MASK 
(1 = INTERRUPTS 
ARE 
MASKED) 


PRECISION 
CONTROL 
(II 


ROUNDING 
CONTROL 
III 


INFINITY 
CONTROL 
(0 = PROJECTIVE, 
1 =AFFINE) 


(RESERVED) 


3. ZERO DIVISOR: The divisor 
is zero while 
the 
dividend 
is 
a 
non-infinite, 
non·zero 
number. 
Again, the 8087 will generate the code for infini- 
ty if this exception 
is masked. 


4. UNDERFLOW: 
The result 
is non-zero 
but too 
small 
in magnitude 
to fit 
in the specified 
for- 


mat. If this 
exception 
is masked 
the 8087 will 
denormalize 
(shift 
right) 
the fraction 
until 
the 


exponent 
is in range. 
This 
process 
is called 


gradual 
underflow. 


5. DENORMALIZED 
OPERAND: 
At 
least 
one 
of 
the operands 
or the result 
is denormalized; 
it 


has 
the 
smallest 
exponent 
but 
a 
non-zero 
significand. 
Normal 
processing 
continues 
if 


this exception 
is masked 
off. 


6. INEXACT 
RESULT: If the true result 
is not ex- 


actly representable 
in the specified 
format, 
the 
result 
is 
rounded 
according 
to 
the 
rounding 
mode, and this 
flag is set. If this 
exception 
is 
masked, 
processing 
will 
simply 
continue. 


The 
iSBC 
337 
module 
is 
supported 
by 
Intel's 
ASM-86/88 
Assembly 
Language 
and 
PUM·86/88 
Systems 
Implementation 
Language. 
In addition 
to 
the instructions 
provided 
in the languages 
to sup· 


port 
the 
additional 
math 
functions, 
a software 
emulator 
is also available 
to allow 
the execution 
of iAPX 86/20 instructions 
without 
the need for the 
iSBC 337 module. This allows 
for the development 
of software 
in an environment 
without 
the iAPX 
86/20 processor 
and then transporting 
the code to 
its final 
run time environment 
with 
no change 
in 
mathematical 
results. 


Physical Characteristics 


Width 
- 
5.33 cm (2.100") 


Length 
- 
5.08 cm (2.000 ") 


Height 
- 
1.82 cm ( .718") 
iSBC 337 board + 
host board 


Weight 
- 
17.33 grams (.576 oz.) 


Operating Temperature 
- 
O°C to 55°C 


Free air moving 
across 
base board and iSBC 337 
module. 


Relative 
Humidity 
- 
Up to 90% R.H. without 
con- 


densation. 


142887·001 - 
iSBC 337 MULTIMODULE 
Numeric 


Data Processor 
Hardware 
Reference 
Manual (NOT 
SUPPLIED) 


Manuals may be ordered from any Intel sales repre- 
sentative, 
distributor 
office, 
or from Intel Literature 
Department, 
3065 
Bowers 
Avenue, 
Santa 
Clara, 


California 
95051. 


Part Number 
SBC 337 
Description 
MULTIMODULE Numeric 
Data 
Processor 


inter 


iSBX 332 
FLOATING 
POINT MATH 
MULTIMODULE 
BOARD 


• ISBX bus compatible 
high speed 
floating point math expansion 


.4 
MHz operation 


• Compatible with proposed IEEE format 
and existing Intel floating point 
standard 


• Single (32-bit)/double 
(64·bit) precision 
arithmetic and data manipulation 
commands 


• Performs functions independently 
and 
concurrently with the MULTIBUS host 
board 


• Add, subtract, multiply and divide 


functions 


• iSBX bus on-board expansion elimi- 


nates MULTIBUS system bus latency 
and increases system throughput 


The Intel'" 
iSBX 332 Floating 
Point Math MULTIMODULE 
Board is a member 
of Intel's 
new line of iSBX bus compatible 


MULTIMODULE 
products. 
The iSBX 
MULTIMODULE 
board 
plugs 
directly 
into 
any iSBX bus compatible 
host 
board 


offering 
incremental 
on-board 
expansion_ 
The iSBX 332 module 
performs 
single 
(32-bit) and double 
(54-bit) precision 


floating 
point 
add, subtract, 
multiply, 
and divide 
functions 
compatible 
with 
the proposed 
IEEE floating 
point 
standard. 


The command 
operations 
run entirely 
independent 
of the host 
board 
permitting 
efficient 
concurrent 
processing. 
The 
iSBX board is closely 
coupled 
to the host board through 
the iSBX bus, and as such, offers 
maximum 
on-board 
perform- 


ance and frees 
MUL TIBUS 
system 
traffic 
for other 
system 
resources. 
In addition, 
incremental 
power 
dissipation 
is 


minimal 
requiring 
only 2.73 watts 


The iSBX 332 module uses the Intel'" 8232 Floating 
Point Processor (FPP) to accomplish high speed math 
operation. The system software may communicate with 
the iSBX 332module across the iSBX bus using I/O readl 
write 
commands. 
All 
transfers, 
including 
operand, 


result, status, and command information, 
take place 
over an 8-bit 
bidirectional 
data bus. Operands are 
pushed onto 
an internal 
stack and commands are 


issued to perform operations on the data stack. Results 
are then available to be retrieved from the stack. A 
status byte may be read to monitor execution comple- 
tion and the nature of the result (zero,sign, or errors). In 
addition, control 
logic is included on the iSBX 332 
module to facilitate 
single instruction 
software reset 


control. 


Command 
Functions 


The iSBX 332 module commands fall into three catego- 
ries: single precision arithmetic, double precision arith- 
metic and data manipulation (see Table 1). There are 
four arithmetic operations that can be performed with 
single precision (32-bit)or double precision (54-bit)float- 
ing point numbers: add, subtract, mUltiply and divide. 
These operations 
require 
two 
operands. The 8232 
assumes that these operands are located in the internal 
stack as Top of Stack (TOS)and Next on Stack (NOS). 
The result will always be returned to the previous NOS 
which becomes the new TOS. Results from an operation 
are of the same precision and format as the operands. 


The results will be rounded to preserve the accuracy. In 
addition to the arithmetic operations, the 8232 imple- 
ments 
eight 
data 
manipulating 
operations. 
These 


include 
changing 
the 
sign 
of 
a double 
or 
single 


precision operand located in TOS, exchanging single 
precision operands located at TOS and NOS, as well as 
copying and popping single or double precision oper- 
ands. See also the sections 
on status register and 
operand formats. 


The execution times of the commands are all data 
dependent. Table 2 shows one example of each com- 
mand execution time. 


Interrupt 
Requests 


There are two interrupt lines from the FPPthat may gen- 
erate an interrupt request to the host: END (MINTR1) 
and ERINT (MINTRO).The END interrupt line is active 
upon command completion and the ERINTline is active 
when the current command execution results in an error 
condition. The error conditions are: attempt to divide by 
zero, exponent overflow and exponent underflow. Both 
the END and ERINT signals are cleared by a reset or 
status register read. 


Installation 


The iSBX332 module plugs directly into the female iSBX 
connector 
on the host 
board. The module 
is then 


secured at one additional point with nylon hardware to 
insure the mechanical security of the assembly (see 
Figures 1 and 2). 


INTEL 
ISBX 
332 
MUL T1MODULE 
BOARD 


HOST 
BOARD 
/ 


. 
INTEL 
iSBX 
Y.·,,· 
_MULTIMODULE 


r:-;' :::. 
. 
CONNECTOR 


V 


Command 
Bits 


Mnemonic 
Description 


7 6 5 4 
3 2 
1 0 


X 0 0 0 0 0 0 
1 
SA DO 
Add 
ros 
to 
NOS 
single 
precision 
and 
result 
to 
NOS. 
Pop 
stack. 


X 0 0 0 0 0 
1 0 
SSUB 
Subtract 
ros 
from 
NOS 
single 
precision 
and 
result 
to NOS. 
Pop stack. 


X 00 
0 0 0 
1 1 
SMUL 
Multiply 
NOS 
oy ros 
single 
precision 
and 
result 
to 
NOS. 
Pop 
stack. 


X 0 0 0 0 
1 o 0 
SDIV 
Divide 
NOS 
by ros 
single 
precision 
and 
result 
to NOS. 
Pop stack. 


X 0 0 0 0 
1 o 
1 
CHSS 
Change 
sign 
of ros 
single 
precision 
operand. 


X 0 0 0 
0 
1 1 0 
pros 
Push 
single 
precision 
operand 
on ros 
to NOS. 


X 0 000 
1 1 1 
POPS 
Pop single 
precision 
operand 
from 
ros. 
NOS 
becomes 
ros. 


X 0 0 0 
1 o 0 0 
XCHS 
Exchange 
ros 
with 
NOS 
single 
precision. 


X 0 
1 0 
1 1 o 1 
CHSD 
Change 
sign 
of ros 
double 
precision 
operand. 


X 0 
1 0 
1 1 1 0 
prOD 
Push 
double 
precision 
operand 
on ros 
to 
NOS. 


X 0 
1 0 
1 1 1 1 
POPD 
Pop double 
precision 
operand 
from 
ros. 
NOS 
becomes 
ros. 


XOOOOOOO 
CLR 
CLR 
status. 


X 0 
1 0 
1 001 
DADD 
Add 
ros 
to 
NOS 
double 
precision 
and 
result 
to 
NOS. 
Pop 
stack. 


X 0 
1 0 
1 0 
1 0 
DSUB 
Subtract 
ros 
from 
NOS 
double 
precision 
and 
result 
to NOS. 
Pop 
stack. 


X 0 
1 o 
1 011 
DMUL 
MUltiply 
NOS 
by ros 
double 
precision 
and 
result 
to NOS. 
Pop stack. 


X 0 
1 o 1 100 
001V 
Divide 
NOS 
by ros 
double 
precision 
and 
result 
to NOS. 
Pop 
stack. 


NOTE: 


x;:: Don't care. Operation 
for bit combinations 
not listed above is undefined. 


Command 
TOS 
NOS 
Result 
Clock 
Periods 
Time(j1s) 


SADD 
3F800000 
3F800000 
40000000 
58 
14.5 


SSUB 
3F800000 
3F800000 
00000000 
56 
14.0 


SMUL 
40400000 
3FCOOOOO 
40900000 
198 
49.5 


SDIV 
3F800000 
40000000 
3FOOOOOO 
228 
57.0 


CHSS 
3F800000 
- 
BF800000 
10 
2.5 


PTOS 
3F800000 
- 
- 
16 
4.0 


POPS 
3F800000 
- 
- 
14 
3.5 
XCHS 
3F800000 
40000000 
- 
26 
6.5 


CHSD 
3FFOOOOOOOOOOOOO - 
B FFOOOOOOOOOOOOO 
24 
6.0 


prOD 
3FFOOOOOOOOOOOOO - 
- 
40 
10.0 


PO PO 
3FFOOOOOOOOOOOOO 
- 
- 
26 
6.5 


CLR 
3FFOOOOOOOOOOOOO 
- 
- 
4 
1.0 


DADO 
3FFOOOOOAOOOOOOO 
8000000000000000 
3FFOOOOOAOOOOOOO 
578 
144.5 


DSUB 
3FFOOOOOAOOOOOOO 
8000000000000000 
3FFOOOOOAOOOOOOO 
578 
.144.5 


DMUL 
BFF8000000000000 
3FF8000000000000 
C0020000000000do 
1748 
437.0 


DDIV 
BFF8000000000000 
3FF8000000000000 
BFFOOOOOOOOOOOOO 
4560 
1140.0 


NOTE: 


TOS, NOS and result are in hexadecimal; 
clock period is in decimal. 


Word Size 


Data 
- 
8 Bits 


Function 
Type of Operation 
Isax Connector 
Port 
Address 


Data Transfer 
Read or Write 
XO, X2, X4, or X6 


Command Transfer 
Write 
Xl, 
X3, X5, or X7 


Status Transfer 
Read 
Xl, X3, X5, or X7 


Reset 
Write 
X8 through 
XF 


NOTE: 


The port addresses 
are determined 
on the host iSBC microcomputer. 
Refer to the Hardware 
Reference 
Manual for your host iSBC microcom- 


puter to determine 
the first digit (X) of the connector 
port address. 


Arithmetic 
Functions 


See Table 1 


Floating 
Point Format 


Single 
Precision 
Floating 
Point (32 Bits) 


, _~~_~EIMPLIED 
BIT 
[~=LE1_ 


31 
30 
23 
22 


Bit 31: 
S = Sign of the mantissa. 
1 represents 
neg- 


ative and 0 represents 
positive. 


Bits 23-30: 
E = These 
8 bits 
represent 
a biased 
expo- 


nent. The bias is 27 - 
1= 127. 


Bits 0-22: 
M = 23-bit mantissa. 
Together 
with the sign 


bit, the mantissa 
represents 
a signed 
frac- 


tion in sign·magnitude 
notation. 
There is an 


implied 
1 beyond 
the 
most 
significant 
bit 


(bit 22) of the mantissa. 
In other words, 
the 


mantissa 
is assumed 
to be a 24-bit normal- 


ized quantity 
and the most 
significant 
bit, 


which 
will 
always 
be 1 due 
to normaliza- 


tion, 
is 
implied. 
The 
FPP 
restores 
this 


implied 
bit 
internally 
before 
performing 


arithmetic, 
normalizes 
the result, and strips 


the implied 
bit before 
returning 
the results 


to the external 
data bus. The binary point 
is 


between 
the 
implied 
bit and bit 22 of the 


mantissa. 


FI~PLlED 
BIT 


52 
51 


Bit 63: 
S = Sign of the mantissa. 
1 represents 
neg- 


ative and 0 represents 
positive. 


Bits 52-62: 
E= Biased 
exponent. 
The bias 
is 210 - 
1= 


1023. 


Bits 0-51: 
M = 51·bit mantissa. 
Together 
with the sign 


bit, the mantissa 
represents 
a signed 
frac· 


tion in sign·magnitude 
notation. 
There is an 
implied 
1 beyond 
the 
most 
significant 
bit 


(bit 51) of the mantissa. 
In other words, 
the 


mantissa 
is assumed 
to be a 53-bit normal- 


ized quantity 
and the most 
significant 
bit, 


which 
will 
always 
be a 1 due 
to 
normal· 


ization, 
is implied. 
The 
FPP restores 
this 


implied 
bit 
internally 
before 
performing 


arithmetic, 
normalizes 
the result, 
and strips 


the implied 
bit before 
returning 
the result 


to the external 
data bus. The binary point 
is 


between 
the 
implied 
bit and bit 
51 of the 


mantissa. 


Status Byte 


Contains the following information: 


Bit 0 
Reserved. 


Bit 1 
Exponent Overflow (V):When 1, this bit indicates 
that exponent overflow has occurred. Cleared to 
zero otherwise. 


Bit 2 
Exponent Underflow (U): When 1, this bit indi- 
cates 
that 
exponent 
underflow 
has occurred. 


Cleared to zero otherwise. 


Bit 3 
Divide Exception (D): When 1, this bit indicates 
that an attempt to divide by zero has been made. 
Cleared to zero otherwise. 


Bit 4 
Reserved. 


Bit 5 Zero (Z):When 1, this bit indicates that the result 


returned to TOS after a command is all zeros. 
Cleared to zero otherwise. 


Bit 6 
Sign (S):When 1, this bit indicates that the result 
returned to TOS is negative. Cleared to zero other- 
wise. 


Bit 7 
Busy: When 1, this bit indicates the APU is in the 
process of executing a command. It will become 
zero after the command execution is complete. 
All other status bits should be considered to be 
undefined if this bit is set. 


Access Time 


Read 
- 
1900 ns (max.) 
Write - 
1900 ns (max.) 


NOTE: 


Actual 
transfer 
speed 
is dependent 
upon the cycle 
time 
of the host 


microcomputer. 
The listed times assume no operation 
in progress. If an 


operation 
is executing 
when an access is attempted, 
the command 
exe- 


cution 
time must be added to the above times for all accesses 
except 


status read 


Interrupts 


Two interrupt requests may originate from the FPP indio 
cating command completion (END)and error conditions 
(ERINT). 


Interface 


iSBX Bus - 
All signals TTL compatible 


Physical Characteristics 


Width 
- 
6.35 cm (2.50 in.) 


,Length - 
9.40 cm (3.70 in.) 


Height· - 
2.04 cm (0.80 in.) iSBX 332 Board 


- 
2.86 cm (1.13 in.) iSBX 332 Board + Host 
Board 
Weight - 
51 gm (1.79 oz) 


·See 
Figure 2 


Electrical 
Characteristics 
DC Power Requirements 
Vcc= 
+5V ±5~% 
Icc=365 
mA max. 


voo= 
+12V ±5% 
IDD=75mAmax. 


Environmental 


Operating Temperature - 
O·C to 55·C 


Free moving air across the base board and iSBX board. 


Reference 
Manual 


9803204·01- 
iSBX 332 Floating Point Math 


MULTIMODULE Board (NOT SUPPLIED) 


Reference Manuals may be ordered from any Intel sales 
representative, distributor office or from Intel Literature 
Department, 3065 Bowers Ave., Santa Clara, California 
95051. 


Part Number 


SBX 332 


Description 


Floating Point Math MULTIMODULE 
Board 


iSBX 331 
FIXED/FLOATING 
POINT MATH 
MULTIMODULE BOARD 


• iSBX bus compatible 
high speed 
fixedlfloating 
point math expansion 


• 4 M Hz operation 


• Fixed point single and double precision 
(16/32·bit) 


• Floating point double precision (32·bit) 


• Binary data formats 


• Add, subtract, mUltiply and divide 


• Trignometric and inverse trigonometric 
functions 


• Square root, log, and exponential 


functions 


• Float·to·fixed and fixed·to·f1oat 


conversions 


• End of operation interrupt 


• Software reset control 


• Low power requirements 


• iSBX bus on·board expansion elimi· 


nates MULTIBUS system bus latency 
and increases system throughput 


The Intel'" 
iSBX 331 Fixed/Floating 
Point Math MULTIMODULE 
Board is a member of Intel's 
new line of 


iSBX bus compatible 
MULTIMODULE 
products. 
The iSBX MULTIMODULE 
board plugs directly 
into any 


iSBX bus compatible 
host board offering 
low cost incremental 
on-board expansion. 
As a result, any iSBX 


bus compatible 
host board may be expanded 
to perform 
high speed math computations, 
affording 
up to a 
40 x 
improvement 
in speed compared 
to software 
math. The iSBX 331 module 
performs 
single/double 


(16/32-bit) precision 
fixed point plus double (32-bit) precision 
floating 
point arithmetic 
operations. 
In addi- 


tion, the module 
performs 
transcendental, 
data manipulation, 
and fixed to float/float 
to fixed point conver- 
sion operations. 
The command 
operations 
run entirely 
independent 
of the host board permitting 
efficient 
concurrent 
processing. 
The iSBX board is closely 
coupled 
to the host board through 
the iSBX bus, and as 
such, 
offers 
maximum 
on-board 
performance 
and 
frees 
MULTIBUS 
system 
traffic 
for other 
system 


resources. 
Incremental 
power dissipation 
is minimal 
requiring 
only 2.73 watts. 


FUNCTIONAL 
DESCRIPTION 


The iSBX 331 module 
uses the Intel 8231 Arithme- 
tic 
Processing 
Unit 
(APU) 
to 
accomplish 
high 


speed (4 MHz) math operation. 
The system 
soft- 


ware may communicate 
with the iSBX 331 module 


across 
the 
iSBX 
bus 
using 
I/O read/Write 
com- 
mands. 
All 
transfers, 
including 
operand, 
result, 
status, and command 
information, 
take place over 


an 
8-bit 
bidirectional 
data 
bus. 
Operands 
are 


pushed onto an internal 
stack and. commands 
are 


issued to perform 
operations 
on the data. Results 


are then 
available 
from 
the stack. 
A status 
byte 


may be read to monitor 
execution 
completion 
and 


the nature of the result (zero, sign, or errors). In ad- 
dition, 
control 
logic 
is included 
on the iSBX 331 


module 
to 
facilitate 
single 
instruction 
software 


reset control. 


Command Functic;ms 


The iSBX 331 module 
commands 
fall 
into 
three 


categories: 
double 
precision 
floating 
point, single 


precision 
fixed 
point, and double 
precision 
fixed 


point (see Table 1). There are four arithmetic 
oper- 


ations 
that 
can 
be performed 
in either 
fixed 
or 
floating 
point 
numbers: 
add, subtract, 
multiply, 
and 
divide. 
These 
operations 
require 
two 
oper· 
ands. The 8231 assumes 
these 
operands 
are lo- 
cated 
in the internal 
stack 
as Top of Stack (TOS) 
and Next on Stack (NOS). The result will always be 


returned 
to TOS. There are four types of transcen· 


dental 
operations 
that can be performed 
in float· 


ing point 
numbers: 
trigonometric 
functions, 
loga- 


rithms, 
exponentials, 
and 
square 
roots. 
The 
re- 


sults of these operations 
will be returned 
to TOS. 


There are four types 
of data manipulation 
opera- 


tions that can be performed 
in either fixed or float- 


ing point numbers: 
sign change of TOS, exchange 


of TOS and NOS and copying 
or popping 
operands 


onto or off of TOS. Fixed to floating 
point conver- 


sion can be performed 
on floating 
point 
instruc· 


tions 
and floating 
point 
to fixed point 
conversion 


can be performed 
on fixed 
point 
instructions. 


The execution 
times of the commands 
are shown 


in Table 2. 


Interrupt Requests 


There is one interrupt 
line from the APU that may 


generate 
an interrupt 
request 
to the 
host: 
END 


(MINTRI). 
The END interrupt 
line 
is active 
upon 


command 
completion. 
The END signal 
is cleared 


by a reset or status 
register 
read. 


Installation 


The 
iSBX 
331 
module 
plugs 
directly 
into 
the 


female 
iSBX connector 
on the 
host 
board. 
The 


module 
is then 
secured 
at one additional 
point 


with 
nylon 
hardware 
to 
insure 
the 
mechanical 


security 
of the assembly 
(see Figures 
1 and 2). 


INTEL 
iSBX 331 


MUl 
TIMOOUlE 
BOARD 


Hex 
Stack Contents 
Status 
Flags 
Instruction 
Description 
After 
Execution(1) 
Code 
A 
B 
C 
D 
Affected(3) 


ACOS 
Inverse 
Cosine 
of A 
0 
6 
R 
U 
U 
U 
S,l, E 


ASIN 
Inverse 
Sine 
of A 
0 
5 
R 
U 
U 
U 
S,l, E 


ATAN 
Inverse 
Tangent 
of A 
0 
7 
R 
B 
U 
U 
S,l 


CHSF 
Sign 
Change 
of A 
1 
5 
R 
B 
C 
0 
S,l 


COS 
Cosine 
of A (radians) 
. 
0 
3 
R 
B 
U 
U 
S,l 


EXP 
eA Function 
0 
A 
R 
B 
U 
U 
S,l, E 


FAOO 
Add 
A and 
B 
1 
0 
R 
C 
0 
U 
S,l, E 


FOIV 
Divide 
B by A 
1 
3 
R 
C 
0 
U 
S,l, E 


FLTD 
32-Bit 
Fixed 
to 
Floating 
Point 
Conversion 
1 
C 
R 
B 
C 
U 
S,l 


FLTS 
16-Bit 
Fixed 
to Floating 
Point 
Conversion 
1 
0 
R 
B 
C 
U 
S,l 


FMUL 
Multiply 
A and 
B 
1 
2 
R 
C 
0 
U 
S,l, E 


FSUB 
Subtract 
A from 
B 
1 
1 
R 
C 
D 
U 
S,l, E 


LOG 
Common 
Logarithm 
(base 
10) of A 
0 
8 
R 
B 
U 
U 
S,l, E 


LN 
Natural 
Logarithm 
of A 
0 
9 
R 
B 
U 
U 
S,l, E 


POPF 
Stack 
Pop 
1 
8 
B 
C 
0 
A 
S,l 


PTOF 
Stack 
Push 
1 
7 
A 
A 
B 
C 
S,l 


PUPI 
Push 
•. onto 
Stack 
1 
A 
R 
A 
B 
C 
S,l 


PWR 
BA Power 
Function 
0 
B 
R 
C 
U 
U 
S,l, E 


SIN 
Sine 
of A (radians) 
0 
2 
R 
B 
U 
U 
S,l 


SORT 
Square 
Root 
of A 
0 
1 
R 
B 
C 
U 
S,l, E 


TAN 
Tangent 
of A (radians) 
0 
4 
R 
B 
U 
U 
S,l, E 


XCHF 
Exchange 
A and 
B 
1 
9 
B 
A 
C 
0 
S,l 


Hex 
Stack Contents 
Status 
Flags 
Instruction 
Description 
After 
Execution!') 
Code 
A 
B 
C 
D 
Affected(3) 


CHSD 
Sign 
Change 
of A 
3 
4 
R 
B 
C 
D 
S,l,O 


DADO 
Add 
A and 
B 
2 
C 
R 
C 
D 
A 
S,l, 
C, E 


DOIV 
Divide 
B by A 
2 
F 
R 
C 
0 
U 
S,l, E 


DMUL 
Multiply 
A and 
B (R = lower 
32 bits) 
2 
E 
R 
C 
D 
U 
S,l,O 


DMUU 
Multiply 
A and 
B (R = upper 
32 bits) 
3 
6 
R 
C 
D 
U 
S,l,O 


DSUB 
Subtract 
A from 
B 
2 
0 
R 
C 
D 
A 
S, l,C,O 


FIXO 
Floating 
to 
Fixed 
Point 
Conversion 
1 
E 
R 
B 
C 
U 
S,l,O 


POPO 
Stack 
Pop 
3 
8 
B 
C 
D 
A 
S,l 


PTOO 
Stack 
Push 
3 
7 
A 
A 
B 
C 
S, l 


XCHD 
Exchange 
A and 
B 
3 
9 
B 
A 
C 
D 
S, l 


Hex 
Stack 
Contents 
Status 
Flags 
Instruction 
Description 
After 
Executionl2) 


Code 
Au AL 
Bu 
BL Cu CL 
Du DL 
Affected(3) 


CHSS 
Change 
Sign 
of Au 
7 
4 
R 
AL 
Bu BL 
Cu CL 
Du DL 
S,l,O 


FIXS 
Floating 
to Fixed 
Point 
Conversion 
1 
F 
R 
Bu BL 
Cu CL 
U 
U 
U 
S,l,O 


POPS 
Stack 
Pop 
7 
8 
AL 
Bu BL Cu CL 
Du DL Au 
S,l 


PTOS 
Stack 
Push 
7 
7 
Au Au 
AL 
Bu 
BL Cu CL 
Du 
S,l 


SADD 
Add 
Au and 
AL 
6 
C 
R 
Bu BL 
Cu CL 
Du DL Au 
S,l,C, 
E 


SDIV 
Divide 
AL by Au 
6 
F 
R 
Bu BL 
Cu CL 
Du DL 
U 
S,l, E 


SMUL 
Multiply 
AL by Au (R = lower 
16 bits) 
6 
E 
R 
Bu BL 
Cu CL 
Du DL 
U 
S,l, E 


SMUU 
Multiply 
AL by Au (R = upper 
16 bits) 
7 
6 
R 
Bu BL 
Cu CL 
DLl DL 
U 
S,l, E 


SSUB 
Subtract 
Au from 
AL 
6 
D 
R 
Bu BL 
Cu CL 
Du DL Au 
S,l,C, 
E 


XCHS 
Exchange 
Au and 
AL 
7 
9 
AL 
Au 
Bu 
BL Cu CL 
Du DL 
S,l 


NOP 
No Operation 
0 
0 
Au AL 
Bu 
BL Cu CL 
Du DL 


NOTES: 


1. The stack initially 
is composed 
of four 32-bit numbers 
(A, B, C, 0). A is equivalent 
to Top Of Stack (TOS) and B is Next On Stack 


(NOS). Upon completion 
of a command 
the stack is composed 
of: the result (R); undefined 
(U); or the initial contents 
(A, B, C, or 0). 


2. The stack initially 
is composed 
of eight 16-bit numbers (Au, AL, Bu, BL, Cu, CL, ou, OJ. Au is the TOS and AL is NOS. Upon comple- 


tion of a command 
the stack is composed 
of: the resuit (R); undefined 
(U); or the initial 
conten~s (Au, AL, Bu, BL, ... ). 


3. Nomenclature: 
Sign (S); Zero (Z); Overflow 
(0); Carry (C); Error Code Field (E). 


Command 
Mnemonic 
I"Seconds 
Command 
Mnemonic 
I"Seconds 


SADD 
4_25 
ASIN 
1917 
SSUB 
7.5 
ACOS 
1933.5 
SMUL 
21-23.5 
ATAN 
1501.5 
SMUU 
20-24.5 
LOG 
1118.5-1783 
SDIV 
21-23.5 
LN 
1074.5-1739 
DADD 
5.25 
EXP 
948.5-1219.5 
DSUB 
9.5 
PWR 
2072.5-3008 
DMUL 
48.5-52.5 
NOP 
1 
DMUU 
45.5-54.5 
CHSS 
5.75 
DDIV 
52 
CHSD 
6.75 
FIXS 
23-54 
CHSF 
4.5 
FIXD 
25-86.5 
PTOS 
4 
FLTS 
24.5-46.5 
PTOD 
5 
FLTD 
24.5-94.5 
PTOF 
5 
FADD 
13.5-92 
POPS 
2.5 
FSUB 
17.5-92.5 
POPD 
3 
FMUL 
36.5-42 
POPF 
3 
FDIV 
38.5-46 
XCHS 
4.5 
SORT 
200 
XCHD 
6.5 
SIN 
1116 
XCHF 
6.5 
COS 
1029.5 
PUPI 
4 
TAN 
1438.5 


I 
o~r' 


Bits 0-14: 
Values 
in the range from 
- 32, 768 to 


+ 32,767. 
Word Size 


Data-8 
bits. 


On-Board Clock Rate 


4.0 MHz 
±0.1%. 


I 
VALUE 
I 
sl I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I 


o 


Bit 31: 
S = Sign 
of 
operand. 
Positive 
values 


are represented 
by a sign of zero (S = 


0). Negative 
values are represented 
by 


the 
two's 
complemet 
of 
the 
corre- 


sponding 
positive 
value with a sign bit 


equal to 1 (S= 1). 


Bits 0-30: 
Values 
in the range from 
- 2,147,483, 


648 to + 2, 147,483,647. 


Type of 
iSBX 


Function 
Connector 
Operation 
Port Address 


Data Transfer 
Reador Write 
XO, X2, X4, or X6 


Command Transfer 
Write 
Xl, 
X3, X5, or X7 


Status Transfer 
Read 
Xl, 
X3, X5, or X7 


Reset 
Write 
XB through XF 


NOTE: 
The port addresses are determined on the host iSSC micro· 
computer. Refer to the Hardware Reference Manual for your 
host iSSC microcomputer to determine the first digit (X)of the 
connector port addresses. 
I 
EXPONENT 
I 
MANTOSSA 
I 
~I:I I I I I 1 I I I I I I I I I I I I I I I I I I I I I I I 


3130 
2423 
0 


Arithmetic 
Functions 


See Table 1. 


I 
VALUE 
I 


Sill 
III 
I II I I III 
I 
n 
0 


MS = Sign 
of 
the 
mantissa. 
1 repre- 


sents 
negative 
and 0 represents 
posi- 


tive. 


Bits 24-30: ES = the 
exponent 
expressed 
as 
a 


two's 
complement 
7-bit value having a 


range of - 64 to + 63. 


Bits 0-23: 
The mantissa 
is expressed 
as a 24-bit 


(fractional) 
value. 
The 
8231 
APU 
re- 


quires 
that floating 
point 
data be rep- 


resented 
by 
a 
fractional 
mantrssa 


value between 
0.5 and 1 multiplied 
by 


2 raised to an appropriate 
power (expo- 


nent). This is expressed 
as follows: 


Data Formats 


Single 
Precision 
Fixed 
Point (16 bits) 


S = Sign 
of 
the 
operand. 
Positive 


values are represented 
by a sign bit of 


zero (S = 0). Negative 
values are repre- 


sented 
by the 
two"s 
complement 
of 


the corresponding 
positive 
value with 


a sign bit equal to 1 (8= 
1). 


Device Status 


Device status 
is provided 
by means of an internal 


status 
register 
whose format 
is shown 
below: 
I 
8US< 
I 
SIGN 
I 
ZERO I 
ERROR 
CODE 
l-=J 


BUSY: 
Indicates 
that 8231 is currently 
executing 


a command 
(1 = Busy) 


SIGN: 
Indicates 
that the value on the top of stack 


is negative 
(1 = Negative) 


ZERO: 
Indicates 
that the value on the top of stack 


is zero (1 = Value is zero) 


ERROR CODE: 
This 
field 
contains 
an indication 


of the validity 
of the result 
of the last operation. 


The error codes are: 


0000 - 
No error 


1000 - 
Divide by zero 


0100 - 
Square root or log of negative 
number 


1100 - 
Argument 
of inverse 
sine, cosine, 
or 


eX too large 


XX10- 
Underflow 
XX01- 
Overflow 


CARRY: 
Previous 
operation 
resulted 
in carry 
or 


borrow 
from 
most 
significant 
bit. (1 = Carry/Bor- 
row, 0 = No Carry/No 
Borrow.) 


If the BUSY bit in the status 
register 
is a one, the 


other status bits are not defined; 
if zero, indicating 


not busy, the operation 
is complete 
and the other 
status 
bits are defined 
as given above. 


Access 
Time 


Read-1900 
ns (max.) 
Write-1900 
ns (max.) 


NOTE: 
Actual transfer speed is dependent upon the cycle time of the 
host microcomputer. The listed times assume no operation in 
progress. If an operation is executing when an access is at· 
tempted, the command execution time must be added to the 
above times for all accesses except status read. 


Interrupts 


One interrupt 
request 
may originate 
from the APU 


indicating 
command 
completion 
(END). 


Interface 


iSBX Bus-All 
signals 
TTL compatible 


Physical 
Characteristics 


Width-6.35 
cm (2.50 in.) 


Length-9.40 
cm (3.70 in.) 
Height*-2.04 
cm (0.80 in.) iSBX 331 Board 


-2.86 
cm (1.13 in.) iSBX 331 Board + 


Host Board 


Electrical 
Characteristics 


DC Power Requirements 


Vee= + 5V ± 5% 
lee= 365 mA max. 


Voo= 
+ 12V ± 5% 
100= 75 mA max. 


Environmental 


Operating 
Temperature-O°C 
to 55°C 


Free moving 
air across 
the base board and iSBX 


board. 


Reference 
Manual 


142668-01-iSBX 
331 Floating 
Point Math 


MULTIMODULE 
Board (NOT SUPPLIED) 


Reference 
manuals 
may be ordered from any Intel 


sales 
representative, 
distributor 
office 
or 
from 


Intel Literature 
Department, 
3065 Bowers Avenue, 


Santa Clara, California 
95051. 


Part Number 


SBX 331 


Description 


Fixed/Floating 
Point Math 


MUL TIMODULE 
Board 


Systems Software 
5 


iSBC™ 957B 


iAPX 86, 88 INTERFACE 
AND EXECUTION 
PACKAGE 


• Supports 
target 
system 
debugging 
for 


iSBC™ 86/05, 86/12A, 88/25, 88/40 or 
iAPX 86, 88-based applications 


• Interactively 
extends 
the Intellec® 
development 
environment 
to the target 


system 
for code execution 
and 


symbolic 
displays 
of results 


• Supports 
custom 
and iRMX™ 


operating 
systems 
with application 


access 
to ISIS-II files 


• Supports 
the 8087 Numeric 
Processor 


Extension 
(NPX) functions 
for high- 


speed arithmetic 
applications 


• Utilizes 
a parallel 
or serial connection 


between 
the Intellec® Development 


System and the target 
system 


• Provides 
an applications 
bootstrap 


from iRMX™ 86 and 88 file compatible 
peripherals 


The Intel 
iSBC 957B package 
contains 
the necessary 
hardware, 
software, 
cables, 
terminator 
packs and 


documentation 
required 
to interface, 
through 
a serial or parallel 
connection, 
an iSBC 86/05, 86/12A, 
88/25, 


88/40 or iAPX 86, 88 target 
system 
to an MDS 800, Series 
II or Series III Intellec 
Microcomputer 
Develop- 


ment System for full-speed 
execution 
and debugging 
of application 
software. 
The iSBC 957B package sup- 


ports the OEM's 
choice 
of a custom 
operating 
system, 
iRMX 86 Operating 
System 
or iRMX 88 Real-Time 


Multitasking 
Executive 
for the target 
application 
system. 
OEM's 
may utilize 
any iRMX 86, 88 supported 


target system 
peripheral 
for a bootstrap 
of the application 
system 
or have full access to the ISIS-II files of 


the Intellec 
system. 
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The following 
are trademarks 
of Intel 
Corporation 
and 
may be used 
only 
to describe 
Intel 
products: 
Intel, 
CREDIT, 
Index, 
Insite, 
Intellee, 
Library 
Manager, 
Megachassis, 


Micromap, 
MULTIBUS, 
PROMPT,lIPI, 
,wScope, Promware, 
MGS, 
ICE, 
iRMX, 
iSBC, 
iSBX, 
MULTIMOOULE 
and 
iCS.lntel 
Corporation 
assumes 
no responsibility 
for the use 01 any 


circuitry 
other 
than circuitry 
embodied 
in an Intel 
product. 
No other 
circuit 
patent 
licenses 
are implied. 
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Overview 


Extending 
the software 
development 
capabilities 


of 
the 
Intellec 
Microcomputer 
Development 


System, 
the iSBC 957B, iAPX 86, 88 Interface 
and 


Execution 
Package 
provides 
a link 
to executing 


and debugging 
in a target system. 
The application 


software, 
developed 
under 
the 
Intellec-resident 


ISIS-II 
Operating 
System, 
can 
readily 
be down- 
loaded to an iSBC 86, 88 Single Board Computer 
or 


a custom 
iAPX 86, 88 system 
using 
the included 


monitor 
and 
its 
powerful, 
interactive 
debugging 


commands 
via the Intellec 
console. 
Programmers 


can 
effectively 
develop 
applications 
to 
ensure 


timely 
product 
availability. 


Target System Debugging 


The iSBC 
957B package 
includes 
a communica- 


tions 
link and target system 
resident 
monitor 
soft- 
ware for target 
application 
debugging. 
The target 


system 
monitor 
supports 
debugging 
through 
an 


attached 
CRT or the Intellec 
System. 
The Intellec 


resident 
communications 
software 
manages 
the 


link (serial or parallel) 
between 
the Intellec 
system 


and the target 
system. 
The communications 
soft- 


ware 
passes 
the 
appropriate 
console-requested 


commands 
to the monitor 
software. 
The monitor 


software, 
invoked 
interactively 
through 
the Intellec 


system, 
effectively 
exercises 
the object 
modules 


on the target 
system. 
Pre-configured 
EPROM resi- 


dent 
monitors 
are supplied 
for 
the 
iSBC 
86/05, 


86/12A and 88/40 products. 
The monitor 
software 


is configurable 
as to 
the 
selection 
of 
the 
com- 


munication 
link, 
processor 
board, 
numeric 
pro- 


cessor 
extension 
and the 
bootstrap 
loader 
func- 


tions. 
The 
OEM 
would 
burn 
the 
configured 


monitor 
into EPROMs for the target 
system. 


The execution 
command 
environment 
(see Table 


1) supported 
by the resident 
monitor 
loads object 


code 
into memory, 
executes 
it at full speed, 
sets 


breakpoints 
and 
examines 
the 
results. 
The 


monitor 
selectively 
executes 
portions 
of program 


modules 
based 
on 
breakpoints 
and 
single 
step- 


ping 
requests. 
The 
monitor 
also 
provides 
com- 


mands 
to 
examine 
memory, 
manage 
memory 


movement 
by block, 
search 
for values, 
compare 


contents, 
and 
modify 
its 
value. 
Other 
program 


debugging 
information 
is 
provided 
through 
the 


displaying, 
examining 
or modifying 
of the iAPX 86, 


88 registers. 


Numeric Data Processor Support 


Arithmetic 
applications 
utilizing 
the 8087 Numeric 


Processor 
Extension 
(NPX) are fully 
supported 
by 


the 
iSBC 957B Monitor. 
In addition 
to executing 


applications 
with 
the full 
NPX performance, 
pro- 


grammers 
may 
examine 
and 
modify 
the 
NPX's 


registers 
using 
decimal 
and real number 
format. 


Command 
Function 


B 
Bootstraps 
an application 
from the target system's 
peripheral device. 


C 
Compares two memory blocks. 


D 
Displays a memory block's contents. 


E 
Exits the Intellec@-based (APXLOD) program and returns to the ISIS-II Operating System. 


F 
Searches a memory block to find a specified 
constant. 


G 
The GO command transfers 
execution 
to the user program. 
I 
Inputs and displays data obtained from the input port. 


L 
Loads the Intellec@ object file into memory. 


M 
Moves the specified 
memory block. 


N 
The N command displays an instruction's 
single step execution. 


0 
Outputs data to the output port. 


P 
Prints values of literals. 


R 
Runs the program after the iAPX 86, 88 object file is loaded. 


S 
Substitutes 
the input value for the memory location. 


T 
Transfers a block of memory to an Intellec@ file. 


X 
Allows iAPXTM86, 88 or NPX registers to be examined or modified. 


* 
Indicates remainder of the line is a comment. 


The programmer 
feels 
confident 
that correct 
and 
meaningful 
numbers 
are entered 
for the applica- 


tion 
without 
having 
to encode 
and decode 
com- 
plex real, integer, 
and BCD hexadecimal 
formats. 


Easy-To-Use Connection 


The physical 
interface 
between 
the Intellec 
Micro- 


computer 
Development 
System 
and 
the 
target 
iAPX 86, 88 system 
is accomplished 
with the sup- 
plied 
iSBC 957B cables. 
The cabling 
arrangement 
is either a serial or parallel 
line and varies depen.d- 
ing on whether 
the development 
system 
is of the 
Intellec 
MDS 
800 family 
or one 
of 
the 
Intellec 
Series II or III family. All communication, 
including 


data transfer 
and command 
requests, 
occurs 
over 


this 
line. 


As shown 
in Figure 
1, the connection 
to the target 


iSBC 
86/12A 
system 
is accomplished 
with 
the 


iSBC 86/12A serial 
port through 
an RS232C serial 


line interconnected 
to Serial port 1 of an Intel lee 


Series II Model 220 or Model 230 or the CRT port of 
an 
Intel lee 800 
Development 
System. 
In some 


target iSBC application 
systems, 
the serial I/O port 


may not be available 
for debugging. 
The example 


connection, 
shown 
in Figure 
2, shows 
how 
the 


parallel 
port 
of 
the 
iSBC 
86/12A 
board 
is con- 


nected 
through 
the parallel 
cable 
to the UPP port 


of the Intellec 
system. 


Al'lffldtlOn 
tSootstrap 
LOaaer 


The bootstrap 
loader, 
invoked 
from 
a stand-alone 


CRT attached 
to the 
iSBC 
product 
or the 
Intel lee 


console, 
dynamically 
loads the application 
system 


into the target 
system's 
memory 
from 
an attached 


peripheral 
through 
the 
iRMX 
86, 
88 compatible 


bootstrap 
loader. 
This 
configurable 
function 
can 


be included 
with 
the 
iSBC 
957B 
monitor 
and 
in- 
stalled 
in the 
iAPX 86, 88 target 
system. 
The pro- 
grammer 
may load application 
code modules 
or an 


entire 
system 
from 
bubble 
memory, 
floppy 
disk- 


ettes, 
Winchester 
disks 
or other 
iRMX 
supported 


mass 
storage 
devices. 


Application 
Access 
to ISIS·II Files 


Application 
programs 
have read or write 
access 
to 


the 
ISIS-II 
file 
system 
from 
the 
iAPX 86, 88 target 


system 
through 
simple, 
easy-to-use, 
ISIS-like 


routines 
(as shown 
in Table 
2). The 
routines 
are 


used 
by applications 
running 
in the target 
system 


to transfer 
files 
from the ISIS environment 
into the 


environment 
of the target 
system. 
User written 
ap- 
plications, 
utilizing 
the 
target 
operating 
system, 


can 
manipulate 
or 
store 
data 
on 
the 
target 


system's 
peripherals. 


Table 
2. Routines 
for ISIS·II Services 
Available 


to Target 
System 
Applications 


Routine 
Target 
System 
Function 


ATIRIB 
Changes an ISIS-II file attribute. 


CI 
Returns a character input from the 
console. 


CLOSE 
Closes an opened ISIS-II file. 


CO 
Transfers a character 
for console 


output. 


DELETE 
Deletes the specified 
ISIS·II file. 


ERROR 
Displays an error message on the 
Intellec@ console. 


EXIT 
Exits to the target system monitor. 


LOAD 
Loads target system memory with 
ISIS-II object code file. 


OPEN 
Opens an ISIS·II file for access. 


READ 
Reads up to 4096 bytes from an ISIS-II 
file to memory. 


RENAME 
Renames an ISIS·II disk file. 


SEEK 
Seeks to the specified 
ISIS-II file 


location. 


WRITE 
Writes up to 4096 bytes from memory 
to an ISIS-II file. 


Intellec@ Configuration 
Environment 


The Intellec 
Microcomputer 
Development 
System 


is 
utilized 
for 
application 
program 
development 


and 
requires 
the 
following 
to 
support 
the 
iSBC 


957B package: 


1. 64K bytes 
RAM 


2. 
Double 
density 
diskette 
or single 
density 
disk- 
ette 
subsystem 


3. 
ISIS-II 
Operating 
System 
and 
associated 


language 
translators 


Intellec'" 
Serial 
Parallel 


System 
Family 
K Bytes/min 
K Bytes/min 


MDS-800 
37 
96 


Series II, III 
37 
29 


iAPX 86, 88 Target System 
Environment 


Supporting 
the 
iAPX 
86, 88-based 
final 
product 


configuration, 
the iSBC 957B software 
package 
re- 


quires: 


1. iSBC 957B cable and EPROMmed 
monitor 


2. Serial 
or parallel 
interface 
(8251 USART or 8255 


Programmable 
Peripheral 
Interface) 


3. iSBC 
86, 88-based 
single 
board 
computer 
or 


custom 
iAPX 86, 88-based 
board 


Hardware 


SUPPORTED 
iSBC™ 
MICROCOMPUTERS 


iSBC 86/05 Single 
Board Computer 


iSBC 86/12A 
Single 
Board 
Computer 


iSBC 88/25 Single 
Board Computer 


iSBC 88/40 Single 
Board 
Computer 


iSBC 337 Numeric 
Data Processor 


SUPPORTED 
iSBC™ 
PERIPHERAL 


CONTROLLERS 


iSBC 204 Flexible 
Diskette 
Controller 


iSBC 215 Winchester 
Disk Controller 


iSBC 220 SDM Disk Controller 


iSBC 254 Bubble 
Memory 
Board 


SUPPORTED 
iSBX™ 
MULTIMODULE™ 
BOARDS 


iSBX 218 Flexible 
Disk Controller 
(when 
mounted 


on an iSBC 215 controller) 


iSBX 350 Parallel 
110 MULTI MODULE 
Board 


iSBX 351 Serial 
110 MULTIMODULE 
Board 


inter 


iSBC™ 957B Package Contents (Supplied) 


CABLES 


1 - 
Serial I/O port of iSBC or iAPX 86, 88 compat· 
ible product to male RS232C connector 


1 - 
Intellec System RS232Cport to female RS232C 
connector 
1 - 
Parallel load cable to mate between Intellec 
System UPP port and parallel I/O port on iSBC 
or iAPX 86, 88 compatible 
product 


PARALLEL 
INTERFACE 
ADAPTER 


1 - 
Parallel port status adapter for iSBC products 
using parallel cable 


1/0 DRIVER 
AND TERMINATORS 


4 - 
iSBC 901 - 220 ohm/330 ohm terminator packs 


4 - 
iSBC 902 - 1K ohm terminator 
packs 


4 - 
7437 line driver packs 


INTERFACE 
AND 
EXECUTION 
SOFTWARE 


DISKETTES 


1 - 
Single density, ISIS compatible 


1 - 
Double density·, ISIS compatible 


Address 
Supports 


Microcomputer 
RAM 
ROM 
NPX 


iSBCTM 86/05, 
OOOOOH- 
FCOOOH- 
Yes 


86/12A 
007FFH 
FFFFFH 


iSBCTM 88/40 
OOOOOH- 
FDOOOH- 
No 


006FFH 
FFFFFH* 


Reference Manual (Supplied) 


143979·002 
- 
User's Guide for the iSBC 957B, 


iAPX 86, 88 Interface and Execution Package 


Part Number Description 


SBC 957B 
Intellec to iAPX 86, 88 Interface 
and Execution Package including 
software, cables and EPROMs. 


intel~ 


iMMX™ 800 
MULTIBUS®MESSAGE 
EXCHANGE SOFTWARE 


• Supports 
use of multiple 
processors 


on the MULTIBUS@system bus 


• Increases 
total system 
throughput 


• Implements 
Intel·standard 
multi- 


processing 
protocol 


• Supports 
combination 
of 8- and 16·bit 


boards in one design 


• Helps solve critical 
response-time 


problems 


• Includes 
Ethernet· 
devic-e driver 


• Provides hardware-independent 
appli· 
cation 
interface 


• Supports 
iRMX™ 80, iRMX™ 86, and 
iRMX™ 88 applications 


The iMMX 
MULTI BUS Message 
Exchange 
provides 
an Open 
Multiprocessing 
System. 
It llilows 
tasks- 


executing 
on separate 
processors 
to communicate 
by sending 
messages. 
By providing 
an off-the-shelf 


implementation 
of the MULTIBUS Interprocessor 
Protocol, 
it cuts many man-months 
off the typical 
devel- 


opment 
schedule. 
Loosely coupled 
multiprocessing 
makes multiple-microcomputer 
applications 
simple: 
programs 
request 
message transfer 
by means of a small set of systems 
calls - 
the iMMX software 
takes 


care of providing 
reliable 
message 
transfer 
via shared MULTI BUS memory. 


The iMMX product 
is open to high-performance 
applications, 
encourages 
modular 
design 
practices, 
and 


supports 
multiple 
operating 
systems. 
By making 
it easy to use multiple 
processors 
it increases 
total 
system 
thoroughput 
and allows 
processing 
power to be optimized 
for both 110 handling 
and data process- 
ing. Once an initial 
application 
design 
is complete, 
it can be easily enhanced 
by adding 
new tasks and/or 


processors. 
The iMMX product 
allows 
the engineer 
to choose 
from a wide 
range of 8- and 16-bit iSBC 


microcomputers 
- 
from the iSBC 80/24 board to the iSBC 86/30 single board computer. 
The net result is a 


combination 
of performance 
and flexibility 
that 
meets 
the needs 
of a diverse 
set of multiple-micro- 
computer 
applications. 


The lOllowing 
are trademarks 
ollnlel 
Corporation 
and may be used only 
10 describe 
Intel 
products: 
Inlel, 
ICE, iMMX, 
iRMX, 
iSeC, 
iSBX, iSXM, 
MULTIBUS, 
MULTICHANNEL, 


MUl TIMODULE 
and .CS Inlel Corporation 
assumes 
no responsibility 
lor the use 01 any circuitry 
other 
than circuitry 
embodied 
in an Intel product. No other 
circuit 
palent licenses 
are implied 
• 
ETHERNET 
IS a trademark 
01 Xerox Corporallon 


intel 


The 
iMMX 
supports 
high 
performance 
applica- 
tions 
in two 
ways. 
First, 
it 
increases 
the 
total 


system 
thoroughput 
by allowing 
multiple 
pro- 
cessors 
to be easily 
incorporated 
in an applica- 
tion. Second, critical 
response 
time requirements 


can be met by placing 
computing 
power close to 


each critical 
input. 
Application 
programmers 
can 


concentrate 
on added-value 
functions 
while iMMX 
software 
takes 
care of variable 
length 
transfers, 
shared 
memory 
management, 
mutual 
exclusion, 
interprocessor 
interrupts, 
and hardware details. 


By supporting 
modular 
desi,gn, 
iMMX 
software 
provides 
four 
key benefits. 
First, 
each hardware 


module 
can be selected 
or designed 
according 
to 


needs 
of a subsystem; 
the 
iMMX 
800 software 
takes 
care 
of 
the 
integration. 
Second 
a whole 
range of products 
can be created from a few hard- 
ware/software 
modules. 
Third, the breadth of pro- 


ducts available for the industry-standard 
MULTIBUS 


dramatically 
reduces 
the 
amount 
of 
custom- 


design work required to complete 
a system. Finally, 
as customers, 
new 
markets, 
or competition 
re- 


quires, 
performance 
can 
be enhanced 
or 
new 


features 
can be added by adding 
new modules. 


OPEN TO MULTIPLE 
OPERATING 
SYSTEMS 


iMMX software 
supports 
both standard 
Intel iRMX 


operating 
systems 
and custom 
systems. 
Off-the- 


shelf 
support 
is provided 
for iRMX 80, iRMX 86, 


and iRMX 88 applications 
- 
allowing 
the engineer 


to choose 
the best match for each problem. 
In ad- 


dition, 
the 
underlying 
MULTI BUS Interprocessor 


Protocol 
(MIP) 
is completely 
specified 
so that 


custom 
operating 
systems 
and other subsystems 


can be integrated 
with iRMX-based 
subsystems. 


Loosely-Coupled Multiprocessing 


The iMMX 800 software 
supports 
loosely-coupled 


multiprocessor 
systems. 
The software 
interface 
is 
composed 
of 
simple, 
easy-to-use, 
modules. 
By 


supporting 
the addressing, 
data transfer, 
control, 


and memory management 
functions, 
the software 


as shown 
in Figure 
2, divides 
the operation 
into 


three 
functions: 
the virtual 
interface, 
the logical 


protocol, 
and the physical 
protocol. 


The virtual 
interface 
is the application 
task's 
ac- 


cess to the iMMX services. 
Using this interface, 
a 


task can request a connection 
to a particular 
port. 


Using 
the connection, 
the task can request 
that 


messages 
be transferred 
to the task(s) that are re- 


questing 
messages 
from the same port. 


VIRTUAL 
INTERFACE 


LOGICAL 
PROTOCOL 
---. 


~ 
PHYSICAL 
PROTOCOL 


Figure 2. 
Inter-Device 
Task-to-Task 
Communications 
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The logical 
protocol 
supports 
a message 
manager 


function. 
The 
Message 
Manager 
prepares 
the 


message 
for delivery 
to a specific 
destination 
port 


based 
on the 
connection 
specified. 
In addition, 
the 
logical 
protocol 
returns 
status 
information 


about 
the transfer. 


The physical 
protocol 
is implemented 
by VLSI and 


associated 
circuitry. 
This level of protocol 
includes 


data 
flow 
control, 
mutual 
exclusion 
mechanics, 


address 
recognition 
and interactive 
signalling 
re- 


quirements. 


iMMX 
software 
supports 
four different 
inter·device 


signalling 
mechanisms: 
MULTIBUS 
interrupts, 
memory·mapped 
interrupts, 
I/O·port·mapped 
inter· 
rupts 
and polling. 


iRMX™ Uniform 
Interface 


The iMMX 
BOOsoftware 
provides 
a uniform 
inter- 


face 
across 
all 
iRMX 
based 
software 
environ- 


ments. 
The iMMX 
software 
services 
are provided 


as a set of tasks, 
system 
procedures, 
and interrupt 


drives. 


Support 
is 
supplied 
for 
the 
iAPX 
B6/BB·based 


microcomputers 
that support 
the iRMX B6 and the 


iRMX BB Operating 
Systems. 
In addition, 
software 


support 
is provided 
Intel 
BOB5·based products 
via 


the iRMX BOOperating 
System. 
Table 
1 shows 
the 


code 
size requirements 
of each of the iMMX 
con- 


figurations. 
Table 
2 gives 
a complete 
list 
of the 


boards 
that are supported. 


Table 
1. iMMX 
800 Software 
Memory 
Requirements 


Executive 
K Bytes 


iRMXTM80 Operating System 
3.7K Bytes 


iRMXTM88 Operating System 
128K support 
4.8K Bytes 
1MB support 


"Compact" 
5.5K Bytes 


"Large" 
6.3K Bytes 


iRMXTM86 Operating System 
6.6K Bytes 


Table 2. Supported 
Single 
Board 


Computers 


iRMX™ 
80 
iRMX™ 88 
iRMX™ 86 


Operating 
Operating 
Operating 


System 
System 
System 


iSB~ 
80/24 
iSB~86/05 
iSB~86/05 


iSB~ 
80/30 
iSB~86/12A 
iSB~86/12A 


iSB~ 
544 
iSB~86/14 
iSB~86/14 


iSB~ 
569 
iSBC'" 86/30 
iSB~86/30 


iSB~88/25 
iSB~88/25 


iSB~ 
88/40 
iSB~ 
88/40 


iSB~88/45 
iSBC'" 88/45 


Message Transfer 
Mechanism 


iMMX 
multiprocessing 
is based 
on 
a message- 


passing 
model. 
Tasks on each processor 
commun- 


icate 
with 
each 
other 
by sending 
and 
receiving 


messages 
to and from 
ports. 


Table 3 shows 
five 
iMMX 
system 
calls: 
Find 
Port, 


Activate 
Port, Transfer 
Message, 
Deactivate 
Port 


and Lose 
Port. 


Shared Memory Space 


The 
iMMX 
software 
manages 
the 
message 
pass- 


ing 
in 
such 
a way 
that 
a task 
that 
receives 
a 


message 
can 
address 
it 
even 
if 
the 
message 


originated 
in the 
private 
memory 
of another 
pro· 


cessor. 
This 
means 
that, 
when 
appropriate, 
the 


message 
is copied 
into 
memory 
that 
can 
be ad- 


dressed 
by the receiver. 


Interprocessor 
Protocol 
Architecture 


The Intel MULTIBUS 
Interprocessor 
Protocol 
(MIP) 


specifies 
an architecture 
by which 
processes 
ex· 


ecuting 
on different 
MULTIBUS 
single 
board 
com- 


puters 
can 
communicate 
with 
one 
another 
in a 


reliable, 
controlled 
manner 
within 
that 
system. 
A 
system 
can consist 
of a heterogeneous 
set of pro- 
cessors, 
executing 
a heterogeneous 
set 
of real- 


time 
executives 
and application 
software. 


Based 
on 
a simple 
internal 
structure, 
the 
MIP 
specification 
defines 
a functional 
consistency 


across 
several 
product 
lines 
and 
provides 
the 


Function 
Name 
Description 


FIND PORT 
CQFIND 
Find a port and return a connection-ID. 


ACTIVATE PORT 
CQACTV 
Activate a port for receiving messages from other tasks. 


TRANSFER MESSAGE 
CQXFER· 
Transfer a message to a port identified 
by the connection-ID. 


DEACTIVATE PORT 
CQDACT 
Deactivate port. Further messages are returned 
10 the sender. 


LOSE 
CQLOSE 
Loses a connection 
to a port. 


inter 


means 
to support 
efficient 
operation 
in multiple 
processor 
environments. 


Ethernet Device Driver 


The 
iMMX 
800 
package 
provides 
an iSBC 
550 
Ethernet 
Communications 
Controller 
device 


driver. 
This device 
driver 
uses iMMX 
routines 
to 


communicate 
to 
the 
iSBC 
550 
contoller 
(see 
Figure 3). This same approach 
can be used to write 
other iRMX 88 and 86 device drivers. 


iSBC 88/40 


iSBC 88/45 


iSBC 544 (Communications) 


iSBC 569 (Digital) 


iSBC 550 (Communications) 


via Ethernet 
driver 


Reference Manual (Supplied) 


iMMX 800 MULTIBUS Message Exchange 
Reference Manual 


Description 


The 
iMMX 
800 
MUL TIBUS 
Message 
Exchange 


Software 
is a licensed 
product 
that provides 
users 


of Intel Single 
Board Computers 
using 
the iRMX 
80, iRMX 86, and iRMX 88 Operating 
Systems 
a 


standardized, 
memory-based, 
task-to-task 
com- 


munication 
protocol. 
This 
protocol 
provides 
the 


fundamental 
capabilities 
needed to exchange data 


between 
multiple 
8-bit and 16-bit microcomputers 
residing 
on the same MULTIBUS 
system 
bus. 


Part Number 
Description 


MMX 800 ARO 
Single 
Density 
Media. Re- 


quires 
incorporation 
fee for 


each derivative 
work. 


Double 
Density 
Media. Re- 


quires 
incorporation 
fee for 


each derivative 
work. 


iSBC™ Supported Hardware 


SINGLE 
BOARD COMPUTERS 


iSBC 80/24 


iSBC 80/30 


iSBC 86/05 


iSBC 86/12A 


iSBC 86/14 


iSBC 86/30 


iSBC 88/25 


MMX 800 ABY 
Single 
Density 
Media. Includes 


incorporation 
fee buyout. 


MMX 800 BBY 
Double Den.sity Media. Includes 
incorporation 
fee buyout. 


MMX 800 AWX 
Single 
Density 
Media. Update 


service 
for an additional 
year. 


MMX 800 BWX 
Double 
Density 
Media. Update 


service 
for an additional 
year. 


MMX 800 LST 
Human readable 
source 


listings 
for the iMMX 800 soft- 


ware modules. 


Extends 
source 
listing 
up- 


dates for an additional 
year. 


iRMX™ 286R 
OPERATING SYSTEM 


• Real-Time Processor management for 


time critical iAPX 286 applications in 
Real Address Mode 


• Higher performance, complete 


iRMX™ 86 compatibility 


• Complete support of 80287 Processor 


Extension 


• New terminal driver for 8274 Multi 


Protocol Serial Controller (MPSC) 


• New iSBC®251 Bubble Memory Driver 


• Multi-terminal support with multi-user 


human interface 


• On-target system development with 


Universal Development Interface (UDI) 


• Configurable system size and function 


for diverse application requirements 


• All iRMX™ 286R code can be 


(P)ROM'ed to support totally solid state 
designs 


• Powerful utilities for interactive 


configuration and real-time debugging 


• Functions in conjunction with 


iRMX™ 86 Release 5 


The high performance 
iRMXTM 286R Operating 
System, 
functioning 
in conjunction 
with the iRMX 86 Release 
5 
Operating 
System software, is designed to manage and extend the resources of iSBC'" 286 Single Board Computers 
as well as other iAPX 286-based 
Microcomputers 
in Real Address 
Mode. The iRMX 286R Operating 
System is an 


easy-to-use, 
real-time, 
multi-tasking 
and multi-programming 
software system providing 
the capability 
of executing 


the entire configurable 
layers of the iRMX 86 software in the Real Address Mode of the iAPX 286 and the iSBC 286/10 
Single Board Computer. 


The new features 
added to this incremental 
System include 
drivers for both channels 
of an 8274 and a driver for 


the iSBX™ 251 MULTIMODULE™ 
board. 


NEWIN D 


iRMX 
,. 286R 
.• 


The following are trademarks 
01Intel Corporation 
and may be used only to describe Inlel products: Intel, ICE. IMMX, iRMX, i$BC, 
i$BX. i$XM, 
MUl TIBUS, 
Multichannel 
and MUL TIMODUlE 


Inlel Corporahon 
assumes 
no responsibility 
tor the use of any circuitry other than cirCUItry 
embodied 
In an Intel product. 
No other 
CirCUli 
patent licenses are implied 
Information 
contained 
herem supercedes 
previously 
pubhshed speclficallons 
on these devices 
from Intel 
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The iRMX™ 286R Operating 
System is a complete 
set 


of system software modules that provide resource man- 
agement functions 
needed by most computer 
systems. 
These management 
functions are currently available to 
OEMs in Release 5 of the iRMX 86 Operating 
System. 


For a complete 
description 
of the functions, 
their value 


and performance, 
please refer to the Release 5 iRMX 
86 Data Sheet (order number 
210885-001). 


This data sheet describes the new features provided by 
the iRMX 286R Operating 
System. These new features 


add new capabilities specially designed for OEMs wishing 
to take better advantage 
of the speed and performance 


of the recent VLSI microprocessor, 
the iAPX 286. 


New drivers 
provided 
with the iRMX 286R Operating 


System 
include: 


- 
An 8274 terminal 
device driver, to support 
the 


8274 for two channel 
Async support 
of the 


iSBC® 286/1 0 board in RS232 mode. 


- 
Support 
for the iSBX™ 251 Bubble 
Memory 


System, 
installed 
as a custom 
driver. 


The 8274 terminal 
device 
driver 
supports 
two serial 


channels used in RS232 mode and supports all features 
of the iRMX 86 terminal 
support. 
To use the RMX de- 


bugger an iSBX 351 MULTIMODULETM is required. 


The iRMX 286R Operating System is a natural extension, 
growth path for iRMX 86 users offering a higher-perform- 
ance, 
simple 
upgrade. 
The Interactive 
Configuration 


Utility has been enhanced to allow ease of configuration 
of iAPX 286 based microprocessors 
such as the iSBC 


286/10 
single board computer. 


To take best advantage of the iAPX 286 microprocessor 
in applications 
where computers 
are required to perform 


many functions simultaneously, 
the iRMX 286R Operat- 


ing System provides a multi-programming 
environment 


in which 
many independent, 
multi-tasking 
application 


programs 
may run. Each application 
environment 
may 


be treated separately 
to allow application 
programmers 


the flexibility 
to separately 
manage each application's 


resources while developing 
and testing the software for 


each independently. 


The resource management 
functions of the iRMX 286R 


System are supported 
by a number of configurable 
soft- 


ware layers. While many of the functions supplied by the 
innermost 
layer, the Nucleus, 
are required 
by all sys- 


tems, all other functions 
are optional. 
The 1/0 systems, 


for example, 
need not be included 
in systems 
with no 


secondary 
storage 
requirement. 
Each layer provides 


functions 
that encourage 
application 
programmers 
to 


maintain 
an understandable 
structure 
and to develop 


easily maintainable 
programs 
more quickly. 


The components 
of the iRMX 286R Operating 
System 


provide both implicit and explicit management 
of a sys- 


tem's resources. These resources often include the pro- 
cessor's 
time and registers, 
the 80287 Numeric 
Data 


Processor 
Extension, 
up to one megabyte 
of system 


memory, 
up to 57 independent 
interrupt 
sources, 
all 


input and output devices, 
as well as directory 
and data 


files contained on mass storage devices. The Operating 
System makes it easier for designers 
to include 
many 


terminals 
in their systems 
by providing 
multi-terminal 


and multi-user support software, 
improved 
1/0 perform- 


ance, an Interactive Configuration 
Utility, and a sophisti- 


cated Crash Analyzer. 


Supported Software Products 


iRMX 860 
iRMX 86 Development 
Utilities 
Package 


including 
the iAPX 86 and 88 Linker, 


Locater, 
Macro Assembler, 
Librarian, 


and the iRMX 86 Editor 


PASCAL 
86/88 
Compiler 


FORTRAN 
86/88 
Compiler 


PUM 
86/88 
Compiler 


TX-Screen-Oriented 
Editor 


MULTlBUS® Message 
Exchange 
soft- 


ware package 
for iRMX 80, 86, and 88 


application 
systems 


iRMX 861 


iRMX 862 


iRMX 863 


iRMX 864 


iMMX 800 


Supported Hardware Products 


COMPONENTS 


iAPX 80286 Microprocessor 


80287 Numeric 
Processor 
Extension 


iAPX 86 and 88 Microprocessors 


8087 Numeric 
Processor 
Extension 


80130 Operating 
System 
Firmware 
Component 


8253 and 8254 Programmable 
Interval Timers 


8259A Programmable 
Interrupt 
Controller 


8251A USART 


8255 Programmable 
Parallel 
Interface 


8274 USART 2 Channel 
(Serial) Controller 


iSBC' 
MULTIBUS'" 
PRODUCTS 


iSBC 86/12A, 
86/05, 86/14, 86/30, 88/25, 88/40, and 


286/10 
Single Board Computers 


iSBC 204 Flexible 
Disk Controller 


iSBC 206 Hard Disk Controller 


iSBC 208 Flexible 
Disk Controller 


iSBC 215 Winchester 
Disk Controller 


iSBC 220 SMD Disk Controller 


iSBC 251 Bubble 
Memory 
System 


iSBC 254 Bubble 
Memory 
System 


iSBC 534 4-Channel 
Terminal 
Interface 


iSBC 544 Intelligent 
4-Channel 
Terminal 
Interface 
and 


Controller 


iSBX 218 Flexible 
Disk Controller 


iSBX 350 Parallel Port (Centronix-type 
Printer Interface) 


iSBX 351 Serial Communications 
Port 


iSBX 270 CRT; Light Pen and Keyboard 
Interface 


Available Literature 


iRMX 286R Operating 
System 
Installation 
and 


Configuration 
Guide for Release 
1 (145556-001) 


All of the manuals 
listed below are supplied 
with iRMX 


86 Release 
5 and are available 
separately 
under the 


order numbers 
shown. 


Introduction 
to the iRMX 86 Operating 
System 


(9803124-04) 


iRMX 86 Operator's 
Manual (144523-001) 


Master Index for iRMX 86 Release 5 Documentation 


(145015-001) 
(Not available 
until 1983) 


Getting 
Started With The Release 
5 iRMX 86 System 


(145073-001) 
. 


iRMX 86 Installation 
Guide (9803125-05) 


iRMX Configuration 
Guide (9803126-05) 


iRMX 86 Nucleus 
Reference 
Manual (9803122-04) 


iRMX 86 Terminal 
Handler 
Reference 
Manual 
(143324-002) 


iRMX 86 Debugger 
Reference 
Manual 
(143323-002) 


iRMX 86 Basic I/O System 
Reference 
Manual 
(98031 23-05) 


iRMX 86 Loader Reference 
Manual 
(143318-002) 


iRMX 86 Extended 
I/O System 
Reference 
Manual 


(143308-002) 


iRMX 86 Human 
Interface 
Reference 
Manual 
(9803202-003) 


Guide to Writing 
Device Drivers for the iRMX 86 and 


iRMX 88 I/O Systems 
(142926-004) 


iRMX 86 Programming 
Techniques 
(142982-003) 


User's Guide for the iSBC 957B, iAPX 86, 88 Interface 


and Execution 
Package 
(143979-002) 


iRMX 86 Disk Verification 
Utility Reference 
Manual 
(144133-002) 


Runtime 
Support 
Manual for iAPX 86, 88 Applications 
(121776-002) 


iRMX 86 Crash Analyzer 
Reference 
Manual 
(144522-001 ) 


The iRMX 286R facilities described in this data sheet re- 
quire the iRMX 86 R5 Operating System as·a prerequisite. 


For all new iRMX users, there are a number of different 
licensing 
and support options available. 
All options are 


provided on either single or double density ISIS-formatted 
diskettes, 
on 5'14" iRMX 86-formatted 
diskettes, 
or on 


double density iRMX 86-formatted diskettes. ISIS-format 
diskettes 
may be used on Intel Intellec'" Development 


Systems. The iRMX 86-format may be used on any iRMX 
86-based system supporting 
the appropriate 
compilers 


and development 
environment. 


The OEM license options 
listed here allow users to in- 
corporate 
the iRMX 286R Operating 
System into their 


applications. 
Each use requires 
payment 
of an Incor- 


poration 
Fee. 


Other licensing options include prepayment 
of future in- 


corporation 
fees, single use rights for a single machine, 


support 
at a second 
development 
site, and one-year 


support 
service 
extensions. 


Each option includes 90 days of update service that pro- 
vides Software 
Problem 
Report Service and copies of 


System updates that occur during this period. All initial 
licenses 
include the iSDM™ 286 System 
Debug Mon- 


itor and iRMX 286R documentation. 


As with all Intel Software, 
purchase 
of any of these 


options 
requires 
execution 
of a standard 
Intel Master 


Software 
License. 


Part Number 
Description 


RMX 286R KIT ARO 
Single Density, 
OEM License 


RMX 286R KIT BRO 
Double 
Density, 
OEM License 


RMX 286R KIT ERO 
Double 
Density, 
iRMX 
86-format, 
OEM License 
for 


use on iRMX 86-based 
envi- 


ronments 


NOTE: Each option requires previous purchase of iRMX 86 Release 


5. iRMX 286R does not support the Protected Virtual Address 
Mode (PVAM) of the iAPX 286-based microprocessor. 


iSDM™ 286 
iAPX 286 SYSTEM DEBUG MONITOR 


• Development support of iSBC®286-and 
iAPX 286-based applications 


• Real Address Mode (RAM) and 
Protected Virtual Address Mode 
(PVAM) support 


• Universal Development Interface (UDI) 
support via development system 
connection 


• Underlying debugging toolfor 
iRMX™ 286R applications 


• Supports 80287 Numeric Processor 


Extension (NPX) for high-speed math 
applications 


• Program load capability from Intellec® 


Series III Development Systems 


• Bootstrap Loader for iRMX™ 286R, 86, 


and 88 file compatible peripherals 


The Intel iSDMTM286 System Debug Monitor package contains the necessary 
hardware, 
software, cables, PROMs, 


and documentation 
required to interface an iSBC" 286 board or iAPX 286 component applications to an Intellec· 
Series 


III through 
a high-speed 
link. The System Debug Monitor supports an OEM's choice of the iRMXT" 286R Real-Time 


Multitasking 
Operating System or custom operating system, with debugging 
tools to examine CPU registers, memory 
content, 
CPU descriptor 
tables, and other crucial environmental 
details. The Monitor 
also allows programs 
to ac- 


cess files on the development 
system via the internal 
UDI support 
and the serial communication 
link. 


Overview 


The iSDM 286 System 
Debug 
Monitor 
provides 
pro- 
grammers 
of iAPX 286-based 
applications 
with the de- 
bugging tools needed to test new applications 
ranging 
from 
single-user 
systems 
to complex 
op~rating 
systems. 
Programmers 
are given direct access to both 
the Real Address 
(ram) and Protected 
Virtual Address 


(pvam) Modes of the CPU via a simple terminal 
inter- 
face, or via an Intellec Series III Development 
System. 


Universal Development Interface 


Any iRMX 86, Series III, or other UDI-based application 
can be supported by the iSDM 286 Monitor. The Monitor 
emulates 
many of the UDI calls (ram or pvam), 
and 
passes all requests for a file system to the host develop- 
ment station. 
UDI applications 
such as compilers 
and 


other programs 
available 
from Independent 
Software 


Vendors 
can be tested in the target iAPX 286 environ- 
ment immediately. 


Powerful Debugging Commands 


A powerful set of user functions includes commands 
to: 


Examine 
and Modify CPU Registers 


Examine, 
Modify, 
and Move memory 
locations 


Symbolic 
reference 
to variable 
names 


Find and compare 
memory 
contents 


Set program 
breakpoints 


Bootstrap 
load application 
software 


Single-step 
CPU operation 


Change between Real Address 
Mode and Protected 


Virtual 
Address 
Mode 


Formatted Displays 


The iSDM 286 Monitor formats all iAPX 286 pre-defined 
data structures 
into clearly 
understandable 
displays. 


This display 
gives programmers 
a formatted 
view of 


CPU registers 
such as LDTs, GDTs, 
IDTs, Segment 


Selectors, and Task State Segments 
- 
not just a series 


of unconnected 
digits. 


Numeric Data Processor Support 


In addition to executing 
80287 Numeric 
Processor 
Ex- 


tension (NPX) applications 
with full NPX performance, 


programmers 
may examine 
and modify NPX registers 


using decimal 
and real number format. Any location 
in 


memory 
known to contain 
numeric 
values in standard 


real format (IEEE P754) may be examined 
or modified 


using normal decimal notation. In this manner program- 
mers may feel confident 
that correct 
and meaningful 


numbers are available to applications 
without having to 


encode 
and decode 
complex 
real, integer, 
and BCD 


hexadecimal 
formats. 


High-Speed Serial Connection 


Target application 
hardware 
is connected 
to the devel- 


opment system via a serial link capable of 19.2K baud. 
All control operations 
and UDI file manipulations 
occur 


over this link through the cables supplied. 
As shown in 


Figure 
1, the serial link, is supported 
by the iSBC 86 


USART port of the development 
system. 


A 
~ 
OEM RS232C 


/ 
I 
CABLE 


Figure 1. Typical iSDMTM 286 Environment 
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Development System Environment 


Intellec 
MDS Series 
III with 64 KBytes. 


Target System Environment 
- 


Any iAPX 286 system with 8274 (non-vectored 
mode) 
serial link, 8254 timer, and 8259A interrupt 
controller 


such as the iSBC 286/10 Single 
Board Computer. 


PROMs are supplied 
for locations 
OFF8000H through 


OFFFFFFH. 


Part Number 


SDM 286 


Description 


iSBC 286 and iAPX 286 System 
Debug Monitor 
package 
including 
cables, 
PROMs, 
software, 
and 
operator 
manual 


(Not available 
stand alone until 


Q3'83) 


A software 
license 
must be or 


have been executed 


Currently 
available 
only with the 


iSBC 286/10 ES Kit or with the 
iRMX 286R Kit. 


inter 


iRMX™ 88 
REAL·TIME MULTITASKING 
EXECUTIVE 


• Event·driven multitasking executive 
software supports iSBC™ 86/05, 
86/12A, 88/25, 88/40 or iAPX 86, 88 
based applications 


• Small, high-performance, 
PROMable 
executive supports high sample rates 


• Provides simple, intertask communica- 
tions and synchronization 


• Supports the 8087 Numeric 
Processor Extension (N PX) for 
arithmetic applications 


• Supports component or iSBC™·based 


system generation through Interactive 
Configuration 
Utility 


• I/O system provides compatible 
iRMX™ 86 files and device independent 
I/O interface 


• I/O system supports the User Run-time 


Interface (URI) for PUM, PASCAL and 
FORTRAN cC?dedapplication tasks 


• Memory management of full megabyte 


iAPX 86, 88 memory 


The iRMX 88 Real-Time 
Multitasking 
Executive 
is a small, 
event-driven 
single-user 
executive 
system. 


Designed 
for dedicated 
computer 
applications 
using 
iSBC 86/05, 86/12A, 88/25, 88/40 or iAPX 86, 88 


custom 
products, 
the modular software 
package provides 
real-time application 
support 
for PASCAL, FOR- 


TRAN, 
PUM, 
and assembler 
coded 
tasks. 
Application 
tasks 
utilize 
intertask 
communications, 
asyn- 


chronous 
110 control, 
priority-based 
resource 
allocation 
and file 
support 
for the 
iSBC 204, 208, 215, 


215/218, and 220 Disk Controllers, 
and the iSBC 254 Bubble 
Memory 
product. 


The small, 
high 
performance 
iRMX 88 Executive 
can be located 
in EPROM or bootstrapped 
into 
RAM 


memory. The iRMX 88 Executive 
offers features 
that are suitable 
for performance-critical 
process 
control 


applications, 
production 
test stand units, sophisticated 
laboratory 
analysis, 
instrumentation, 
specialized 


data acquisition 
systems 
or monitoring 
stations. 
The iRMX 88 design, 
based upon the iRMX 80 Real-Time 


Executive, 
offers 
iRMX 80-like interfaces 
for those 8-bit applications 
which 
are upgrading 
to 16-bit solu- 


tions 
for the 1 Megabyte 
addressing, 
expanded 
application 
functions, 
and higher performance 
data sam- 


pling requirements. 


The following 
are trademarks 
of Intel 
Corporation 
and may be used 
only 
to describe 
Intel 
products: 
Intel, 
CREDIT, 
Indel(, 
Insite, 
Intallee. 
Library 
Manager. 
Megachassis. 


Micromap, 
MULTIBUS, 
PROMPT, 
UPI, ~Scope. Promware. 
MeS, ICE, IRMX, 
iSBC, ,sex, MULTIMODULE 
and iCS.lntel 
Corporation 
assumes 
no responSibility 
for the use of any 


circuitry 
other 
than circuitry 
embodied 
in an In lei product 
No other 
CIrcuit 
palent 
licenses 
are implied. 


l,\J INTElCOAPORATION, 
1981 
October, 
1981 
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The 
iRMX 
88 
Real-Time 
Multitasking 
Executive 
Software 
package provides 
facilities 
for executing 
tasks concurrently, 
managing 
resources 
and serv- 
icing 
asynchronous 
events 
to 
users 
of 
Intel's 


single 
board 
computers 
and 
custom 
iAPX 
86, 


88-based 
products. 
The foundation 
modules 
sup- 


port 
real-time 
dedicated 
computer 
applications 
with 
priority-based 
task 
scheduling, 
interrupt 


dispatching, 
real-time 
clock 
control 
with 
1 ms 
resolution, 
multiple 
event monitoring 
and control, 


and 
file 
services 
for 
flexible, 
hard, 
Winchester, 
SMD disk units 
and bubble 
memory 
devices. 
The 


software 
package 
includes 
the primary 
modules: 
Nucleus, 
Free Space Manager, 
Terminal 
Handler, 


I/O System 
and Bootstrap 
Loader. The Interactive 
Configuration 
Utility 
(ICU) executes 
on a Series III 
Intellec 
System, 
or 
iRMX 
86 Operating 
System 
with a Universal 
Development 
Interface 
(UDI). 


Event·Driven Multitasking 


The iRMX 88 Executive 
provides a control 
software 
foundation 
called a Nucleus. 
The iRMX88 
Nucleus 
provides 
two major functions: 
first, the facility 
for 
concurrent 
task execution; 
secondly, 
the facility 


for handling 
simultaneous 
asynchronous 
events. 


The structured 
multitasking 
environment 
permits 


segmenting 
of the application 
tasks. The number 
of tasks, 
managed 
by the Nucleus, 
is limited 
only 


by the available 
1 Megabyte 
memory 
space. The 


tasks are prioritized 
such that the highest-ranked 


task 
is executing, 
e.g., an alarm event 
preempts 


the 
lower 
priority 
executing 
task. 
The 
Nucleus 


supports 
255 priority 
levels. 


Since internal 
or external 
events (interrupts) 
occur 
randomly, 
the 
Nucleus 
synchronizes 
the 
event 
with a task. The Nucleus 
supports 
either an inter- 


rupt service 
routine 
or an interrupt 
task. The inter- 
rupt 
service 
routine 
offers 
high-speed 
perform- 


ance 
flexibility 
since 
it masks 
all interrupts 
and 
supports 
burst-rate 
data sample gathering. 
The in- 


terrupt 
task 
is useful 
for 
lower 
frequency 
inter- 


rupts, masking 
only lower priority 
interrupts. 


Small High·Performance 
Executive 


The iRMX 88 Executive 
software 
utilizes 
a simple, 


straightforward 
architecture 
which 
minimizes 
the 


memory 
requirements, 
as shown 
in Table 1. In ad- 


dition, 
the 
modules 
are designed 
to 
be totally 


EPROM resident 
for those 
systems 
where 
mass 


storage 
devices 
cannot 
be used 
because 
of the 


danger of contamination. 


Real-time 
microcomputer 
solutions 
require 
the 
recognition 
of interrupts. 
The performance 
of the 


system 
is with 
respect 
to data 
sample 
rates. 
If 


there is no activity 
in progress 
when an interrupt 


occurs, 
the time to handle that interrupt 
is depend- 


ent on the number 
of instructions 
executed, 
e.g., 


175 microseconds 
interrupt 
latency 
time 
on an 
iSBC 86/12A board. Most real-time 
solutions 
have 


multiple 
events occurring 
and background 
opera- 


tions 
in progress. 
Seldom does a background 
task 


have critical 
sections 
of code which 
cannot 
be in- 


terrupted. 


Intertask Communications 


The iRMX 88 Nucleus 
provides 
a simple, 
easy-to- 


use intertask 
communications 
mechanism 
based 
upon 
a message. 
Messages 
are transferred 
be- 


tween tasks with two basic procedure 
calls, a send 


(RQSEND) and a wait (RQWAIT). Task "A" requests 
the Nucleus 
to RQSEND the pointer 
to a message 


buffer to Task "B" (see Figure 2). The Nucleus 
con- 


trols 
the message 
flow 
by activating 
the higher- 


priority 
Task B, or queuing 
the message 
if a lower- 


priority 
Task B is not waiting 
for the message. The 


receiving 
task 
does an RQWAIT 
to get the mes- 


sage pointer 
and can now access 
the data which 
may be for 
synchronization 
or real-time 
control 


operations. 


TERMINAL 
FREE 
I/O SYSTEM 
MODULE 
NUCLEUS 
SPACE 
HANDLER 
MANAGER 
PHYSICAL"" 
NAMED"" 
BOOTSTRAP 


EPROM" 
3.0 
1.3 
0.6 
20.0 
32.0 
0.5 
(K bytes) 


• amount of code configured 
in EPROM; all numbers are approximate 


•• 
includes one 3K byte device driver (named file plus physical file ·is 34.0K bytes) 


inter 


TASK A 
TASK 
ENTRY 
POINT 


INITIALIZE 
TASK 


1. 


.. 
PERFORM 
FUNCTION 


INITIALIZE 
OPERATION 
(ROSEN 
D) 
(SEND 
MESSAGE) 


WAIT 
FOR 
RESPONSE 
(ROWAIT) 


TASK 
B 
TASK 
ENTRY 
POINT 


INITIALIZE 
TASK 


WAIT 
FOR 
MESSAGE 
(ROWAIT) 


1. 


FROM 
TASK 
A 


PERFORM 
FUNCTION 


SEND 
RESPONSE 
(ROSENO) 


TO TASK 
A 


NAME 


ACCEPT 


CREATE 
EXCHANGE 


DISABLE 
INTERRUPT 


DELETE EXCHANGE 


DELETE TASK 


ENABLE 
INTERRUPT 


INTERRUPT 
SEND 


RESUME 


SEND 


SUSPEND 
TASK 


WAIT 


Numeric 
Data Processor 


The 
iRMX 
88 
Nucleus 
fully 
supports 
the 
8087 


Numeric 
Processor 
Extension 
(NPX) functions 
for 


high-speed 
arithmetic 
functions 
of 
real-time 
ap- 


plications. 
High-performance 
numeric 
processing 


applications, 
which 
utilize 
8-, 16-,32- and 64-bit in- 


tegers, 
32-, 64- and 80-bit floating 
point 
or 18-digit 


BCD operations, 
are accelerated 
up to 100 times 


over 
a iAPX 
86, 88 software 
solution. 
The 
NPX 


functions, 
including 
trigonometric, 
logarithmic 


and 
exponential 
functionals, 
are 
essential 
in 


scientific, 
engineering, 
navigational 
or military 
ap- 


plications. 


Nucleus 
Primitives 


The Nucleus 
performs 
other functions 
as shown 
in 


Table 
2, in addition 
to the message 
communica- 


tions 
management. 
Some primitives 
like CREATE 


TASK 
and 
DELETE 
TASK 
allow 
dynamic 
crea- 


tion/deletion 
of 
tasks 
during 
run-time. 
This 


dynamic 
capability 
allows 
the 
Nucleus 
tables 
to 


Table 2_ Nucleus 
Primitives 


FUNCTION 


Accept 
a message 
from 
specified 
exchange. 
Returns 
message 
ad- 


dress 
if available, 
zero otherwise. 


Create 
task 
by building 
new Task 
Descriptor 
based 
on specified 


Static 
Task Descriptor. 


Create exchange 
at specified 
RAM address. 


Disable 
specified 
interrupt 
level. 


Delete specified 
exchange. 


Delete the task specified. 


Initialize 
message 
portion 
of 
the 
Interrupt 
Exchange 
Descriptor 


associated 
with 
the 
specified 
interrupt 
level 
(the first 
time 
called 


only), and enable 
specified 
interrupt 
level. 


Signals 
specific 
end-of-interrupt 
for the specified 
interrupt 
exchange 


in a user-supplied 
interrupt 
service 
routine. 


Send an interrupt 
message 
to the specified 
interrupt 
exchange. 


Resume 
a task that has previously 
been suspended. 


Send the message 
located 
at "msg-addr" 
to the exchange 
specified 


by "exch-addr." 


Set interrupt 
vector 
address. 
An interrupt 
is to be serviced 
byttle 


user-supplied 
routine 
starting 
at 
the 
address, 
thus 
bypassing 


Nucleus 
interrupt 
software. 


Suspend 
execution 
of the task specified 
by the Task Descriptor. 


Wait at the specified 
exchange 
until 
a message 
is available 
or time 


limit 
expires. 
Return 
address 
of 
system 
timout 
message 
or user 


message. 


expand and accommodate 
infrequently 
used tasks 
which 
are 
loaded 
into 
memory 
from 
a mass 
storage 
device. 


Interactive 
System 
Generation 


The 
iRMX 
88 
Executive 
is 
constructed 
in 
a 
thoroughly 
modular 
manner with the full range of 
facilities 
being 
offered 
in 
library 
modules. 
By 


selecting 
the appropriate 
features 
and combining 


them 
with 
the user-written 
application 
tasks 
the 


generated 
system 
is tailored 
to the application's 


requirements 
minimizing 
memory 
overhead 
for 
unused 
features. 


An 
Interactive 
Configuration 
Utility 
provides 
a 
query-based 
tool 
that 
configures 
the 
iRMX 
88-based 
application. 
Responding 
to 
questions 
from the ICU utility 
program executing 
on a Series 


IIllnteliec 
Microcomputer 
Development 
System or 
an iRMX 86-based system, 
the user quickly 
tailors 


the real-time 
application 
system. 


1/0 System 


The iRMX 88 I/O System 
provides 
an extensive 
facility 
for 
device-independent 
I/O. Through 
a 
series 
of 
supplied 
iRMX 
86 compatible 
device 
drivers, 
the I/O System 
supports 
a wide-range 
of 
iSBC 
peripheral 
controllers. 
Custom 
peripheral 
controllers 
are 
supported 
through 
user-written 
device 
drivers 
which 
are integrated 
with 
the I/O 
System 
at system 
configuration 
time. The device- 
independent 
nature 
of the system 
allows 
use of 
different 
devices 
without 
application 
redesign. 


The I/O System (IOS) procedures 
mar:lage real-time 
file 
operations 
supporting 
both 
sequential 
and 
random 
access 
(see Table 3). The 10S maximizes 


system 
throughput 
by allowing 
multiple 
disk 


operations 
to 
proceed 
in parallel. 
For example, 


files can be "double 
buffered" 
so that the task can 
be processing 
data in one buffer 
while 
the 10S is 
filing 
another. 


The 10S provides 
access to two types of files: 


• 
Named 
Files allow applications 
to refer to col- 


lections 
of bytes (files) by using a name. These 


names are cataloged 
in a directory 
which allows 


files to be accessed 
by different 
tasks. 


• 
Physical 
Files 
allow 
applications 
to 
make 
a 


physical 
connection 
to 
a storage 
device. 


Typically 
used 
for 
simple 
devices 
such 
as 


printers, 
terminals 
or sequential 
data 
logging 


where file structures 
are not necessary. 


The file types are a compatible 
subset of the iRMX 


86 Basic 
I/O System 
with a flat (non-hierarchical) 


directory. 


Bootstrap 
Loader 


The iRMX 88 10S has a Bootstrap 
Loader which 
loads 
a file 
from 
mass 
storage 
into 
system 


memory. The configurable 
Bootstrap 
Loader loads 
the file from a specific 
device, automatically 
from 
the first-ready 
device 
of a designated 
device 
list, 


or accepts 
the file name from a terminal. 
Storing 
the system 
software 
on disk allows 
easier future 


changes 
to the application 
system. 


The iRMX 88 Executive 
provides the User Run-time 
Interface 
(URI). This URI interface, 
in addition 
to 


encompassing 
the I/O System 
services, 
provides 
additional 
functionality 
for tasks. 
The additional 
functionality 
includes 
a trap function 
and memory 
management 
routines 
which 
provide 
the run-time 
foundation 
for 
PASCAL-86, 
FORTRAN-86, 
or 


PUM-86 coded application 
tasks. 


SERVICE 
FUNCTION 


Data Transfer 
CLOSE 
Closes a file connection. 


Services 
OPEN 
Opens a file connection 
for access. 


READ 
Reads a number of bytes from a file. 


SEEK 
Seeks to the indicated 
position. 
TRUNCATE 
Truncates 
a file. 


WRITE 
Writes 
a number of bytes to that file. 


File Connection 
ATTACH 
Attaches 
to a file connection. 


Services 
CREATE 
Creates a file and returns a file connection. 


CONNECTION 
STATUS 
Returns the file connection 
status. 


DELETE 
Marks the file for deletion. 
DETACH 
Detaches 
a file connection. 


RENAME 
Renames an existing 
file. 


Volume 
Preparation 
FORMAT 
Formats 
the disk for files. 


Intellec@ System 
Configuration 
and 


Generation 
Requirements 


Series 
III Intellec 
Microcomputer 
Development 


System with 
UDI support 
and a minimum 
of 2 


diskette drives. 


iRMX™·Based Configuration 
and 


Generation 
Requirements 


iRMX 86-based system with 
UDI support 
and a 


minimum of 2 diskette drives. 


Supported 
Hardware 


ISBC™ SUPPORTED 
MICROCOMPUTERS 


iSBC 86/05 Board 
iSBC 86/12A Board 
iSBC 88/25 Board 
iSBC 88/40 Board 


MASS STORAGE 


iSBC 204 Flexible Diskette Controller 
iSBC 208 Flexible Disk Controller 
iSBC 215A Winchester Disk Controller 
iSBC 215B Winchester Disk Controller 
iSBC 220 SMD Disk Controller 
iSBC 254 Bubble Memory Board 


MUL T1MODULE™ 
BOARDS 


iSBX 218 Flexible Disk Controller (when used with 
the iSBC 215 Controller) 


iSBC 337 Numeric Data Processor 
iSBX 351 Serial I/O Board 


CUSTOM 
iAPX 86, 88·BASED 
SYSTEMS 


REQUIREMENTS 


8253 or 8254 Programmable Interval Timer 
8259A Programmable Interrupt Controller 
8251A USART or iSBX 351 board (when the Ter- 
minal Handler is configured 
into the system). 


8087 Numeric 
Processor 
Extension 
(when NPX 


tasks are configured into the system). 


Reference 
Manuals (supplied) 


143238 - 
Introduction 
to the iRMX 80/88 Real- 


Time Multitasking 
Executives 


143241 - 
iRMX 88 Installation 
Instructions 


143232 - 
iRMX 88 Reference Manual 


142603 - 
iRMX 80/88 Interactive 
Configuration 


User's Guide 


142926 - 
Guide to Writing Devlce Drivers for the 


iRMX 86 and iRMX 88 I/O Systems 
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RMX 88 ABY 
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Density 
ISIS media. 
In- 
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incorporation 
fee 


RMX 88 
A licensed 
product 
which 
in- 
buyout. 
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Nucleus, 
Terminal 
RMX 88 BBY 
Double 
Density 
ISIS media. 
In- 
Handler, 
Free Space Manager, 
eludes 
incorporation 
fee 
and I/O System 
object 
modules. 


Package also includes 
UDI- 
buyout. 


compatible 
Interactive 
Config- 
RMX 88 DBY 
Single 
Density 
RMX-86 media. 


uration 
Utility 
program 
for 
Includes 
incorporation 
fee 


system 
generation 
and a com· 
buyout. 


plete set of manuals. 
Purchase 
RMX 88 AWX 
One year Single 
Density 
ISIS 
price 
includes 
an iRMX 88 
Customer 
Training 
Course 
media 
update 
service. 


credit. 
RMX 88 BWX 
One year Double 
Density 
ISIS 


RMX 88 ARO 
Single 
Density 
ISIS media. 
Re- 
media 
update 
service. 


quires 
derivative 
work incor- 
RMX 88 DWX 
One year Single 
Density 


poration 
fee. 
RMX·88 media 
update 
service. 


RMX 88 BRO 
Double 
Density 
ISIS media. 
Re- 
RMX 88 LST 
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readable 
source 
listings 
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derivative 
work incor· 
for iRMX 88 software. 


poration 
fee. 
RMX 88 LWX 
Update 
service 
for human 
RMX 88 ORO 
Single 
Density 
RMX-86 media. 
readable 
source 
listings. 


Requires 
derivative 
work 
incor· 
RMX 88 RF 
Incorporation 
fee. 
poration 
fee. 


iRMX™ 86 
OPERATING 
SYSTEM 


• Real-time processor management for 


time-critical 
iAPX 86 and iAPX 88 


applications 


• On-target system development with 


Universal Development Interface (UDI) 


• Configurable 
system size and function 


for diverse application 
requirements 


• All iRMX™86 code can be (P)ROM'ed 


to support totally solid state designs 


• Compatible operating system services 


for iAPX 86/30 and 88/30 Operating 
System Processors (iOSpTM86) 


• Multi-terminal 
support with multi-user 


human interface 


• Broad range of device drivers included 


for industry standard MULTIBUS® 
peripheral controllers 


• Expandable to multi-processor 
systems 


with iMMX™800 Message Exchange 
Software 


• Extendable to iAPX 286 systems with 


iRMX™286R option 


• Powerful utilities for interactive 
configuration 
and real-time debugging 


The iRMX™ 86 Operating 
System 
is an easy-to-use, 
real-time, 
multi-tasking 
and muiti-programmming 
software 


system designed 
to manage and extend the resources 
of iSBC® 86 and iSBC 88 Single Board Computers, 
as well 
as other iAPX 86- and iAPX 88-based microcomputers. 
iRMX 86 functions are available in silicon with the iAPX 86/30 
and 88/30 Operating 
System 
Processors, 
in a user configurable 
software 
package, 
and fully integrated 
into the 


SYSTEM 86/300 Family of Microcomputer 
Systems. The Operating System provides a number of standard interfaces 


that allow iRMX 86 applications 
to take advantage 
of industry 
standard 
device controllers, 
hardware 
components, 


and a multitude 
of software packages developed 
by Independent 
Software Vendors (ISVs). Many high-performance 
features extend the utility of iRMX 86 Systems into applications 
such as data collection, 
transaction 
processing, 
and 


process control where immediate 
access to advances in VLSI technology 
is paramount. 
These systems may deliver 


real-time performance 
and explicit control over resources; 
yet also support applications 
with multiple 
users needing 
to simultaneously 
access terminals. 
The configurable 
layers of the System provide services 
ranging from interrupt 
management 
and standard 
device drivers for many sophisticated 
controllers, 
to data-file 
maintenance 
commands 


provided 
by a comprehensive 
multi-user 
human interface. 
By providing 
access to the standard 
Universal 
Develop- 


ment Interface (UDI) for each user terminal, Original Equipment Manufacturers 
(OEMs) can pass program development 


and target 
application 
customization 
capabilities 
to their users. 


The following are trademarks 
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Corporation 
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product. 
No other 
circuit 
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licenses 
are implied. 
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The iRMX 86 Operating 
System 
is a complete 
set of 


system 
software 
modules 
that 
provide 
the resource 


management 
functions 
needed by computer 
systems. 


These management 
functions allow Original Equipment 
Manufacturers 
(OEMs) to best use resources 
available 


in microcomputer 
systems while getting their products 


to market quickly, 
saving time and money. 
Engineers 


are relieved of writing complex system software and can 
concentrate 
instead on their application 
software. 


This data sheet 
describes 
the major features 
of the 


iRMX 86 Operating 
System. 
The benefits 
provided 
to 


engineers 
who write application 
software 
and to users 


who want to take advantage of improving microcomputer 
price and performance 
are explained. 
The first section 


outlines the system resource management 
functions 
of 


the Operating 
System 
and describes 
several 
system 


calls. The second section gives a detailed 
overview 
of 


iRMX 86 features 
aimed at serving 
both the iRMX 86 


system 
designer 
and programmer, 
as well as the end 


users of the product 
into which the Operating 
System 


is incorporated. 


To take best advantage 
of iAPX 86 and 88 micropro- 
cessors in applications 
where the computer 
is required 


to perform many functions simultaneously, 
the iRMX 86 


Operating 
System provides 
a multiprogramming 
envi- 


ronment 
in which many independent, 
multi-tasking 
ap- 
plication programs may run. The flexibility of independent 
environments 
allows application 
programmers 
to sep- 


arately manage each application's 
resources during both 


the development 
and test phases. 


The resource 
management 
functions 
of the iRMX 86 


System are supported 
by a number of configurable 
soft- 


ware layers. While many of the functions supplied by the 
innermost 
layer, the Nucleus, 
are required 
by all sys- 


tems, all other functions 
are optional. 
The I/O systems, 
for example, 
need not be included in systems having no 


secondary 
storage 
requirement. 
Each layer provides 


functions 
that encourage 
application 
programmers 
to 


use modular 
design techniques 
which aid in quick de- 


velopment 
of easily maintainable 
programs. 


The components 
of the iRMX 86 Operating 
System pro- 


vide both implicit 
and explicit 
management 
of system 


resources. 
These resources 
include 
processor 
sched- 
uling, up to one megabyte 
of system memory, 
up to 57 


independent 
interrupt 
sources, all input and output de- 
vices, as well as directory 
and data files contained 
on 


mass storage devices and accessed 
by a number of in- 


dependent 
users. Management 
of each of these system 


resources and how the resources can be shared between 
multiple processors and users is discussed in the follow- 
ing sections. 


Process Management 


To implement 
multi-tasking 
application 
systems, 
pro- 


grammers 
require a method of managing 
the different 


processes 
of their application, 
and for allowing the pro- 


cesses to communicate 
with each other. The Nucleus 


layer of the iRMX 86 System provides a number of facilities 
to efficiently manage these processes, and to effectively 
communicate between them. These facilities are provided 
by system calls that manipulate 
data structures 
called 


tasks, jobs, semaphores, 
regions, and mailboxes. 
The 


iRMX 86 System refers to these structures as "objects". 


Tasks are the basic element of all applications 
built on 
the iRMX 86 Operating 
System. 
Each task is an entity 


capable of executing 
CPU instructions 
and issuing sys- 


tem calls in order to perform a function. 
Tasks are char- 


acterized 
by their register values (including 
those of an 


optional 8087 Numeric 
Processor 
Extension), 
a priority 


between a and 255, and the resources 
associated 
with 


them. 


Each iRMX 86 task in the system is scheduled 
for oper- 


ation by the iRMX 86 nucleus. 
Figure 1 shows the five 


states in which each task may be placed, and some ex- 
amples of how a task may move from one state to an- 
other. The iRMX 86 nucleus 
ensures 
that each task is 


placed in the correct state, defined 
by the events in its 


external 
environment 
and by the task issuing 
system 


calls. Each task has a priority to indicate 
its relative im- 


portance 
and need to respond to its environment. 
The 


nucleus guarantees that the highest priority ready-to-run 
task is the task that runs. 


Jobs are used to define the operating 
environment 
of 


a group of tasks. Jobs effectively 
limit the scope of an 


application 
by collecting all of its tasks and other objects 


into one group. Because the environment 
for execution 


of an application 
is defined by an iRMX 86 job, separate 


applications 
can be efficiently 
developed 
by separate 


development 
teams. 


The iRMX 86 Operating 
System provides 
two primary 


techniques 
for real-time event synchronization 
in multi- 


task applications: 
regions 
and semaphores. 


Regions are used to restrict access to critical sections 
of code and data. Once the iRMX 86 Operating 
System 


gives a task access to resources 
guarded 
by a region, 


no other tasks may make use of the resources, 
and the 


task is given protection against deletion and suspension. 
Regions are typically used to protect data structures from 
being simultaneously 
updated 
by multiple 
tasks. 


Semaphores 
are used to provide mutual exclusion 
be- 


tween tasks. They contain abstract "units" 
that are sent 


between 
the tasks, and can be used to implement 
the 


cooperative 
sharing 
of resources. 


1 (10) 


(NONEXISTENT) 


NOTES: 


(1) 
Task 
is created 


(2) 
Task 
becomes 
highest 
priority 
ready 
task 


(3) 
Task 
gets 
pre·empted 
by one 
with 
higher 
priority 


(4) 
Task 
calls 
SLEEP 
or task 
waits 
at an exchange 


(5) 
Task 
sleep 
period 
has 
ended, 
message 
was 
sent 
to 
waiting 
task 
or wait 
has 
ended 


(6) 
Task 
calls 
SUSPEND 
on self 


(7) 
Task 
suspended 
by other 
than 
self 


(8) 
Task 
suspended 
by other 
than 
self 
or a resume 
that 


did 
not 
bring 
suspension 
depth 
to zero 


(9) 
Task 
was 
resumed 
by other 
task 


(10) 
Task 
IS deleted 


Multi-tasking applications must communicate 
information 
and share system resources among cooperating 
tasks. 
The iRMX 86 Operating 
System assigns a unique 16-bit 


number, 
called a token, to each object created 
in the 
System. 
Any task in possession 
of this token is able to 
access the object. The iRMX 86 Nucleus 
allows tasks 


to gain access to objects, and hence system resources, 
at run-time with two additional 
mechanisms: 
mailboxes 
and object directories. 


Mailboxes 
are used by tasks wishing 
to share objects 


with other tasks. A task may share an object by sending 
the object's token via a mailbox. The receiving task can 
check to see if a token is there, or can wait at the mailbox 
until a token is present. 


Object 
Directories 
are also used to make an object 


available to other tasks. An object is made public by cata- 
loging its token and name in a directory. 
In this manner, 


any task can gain access to the object by knowing 
its 


name, and job environment 
that contains the directory. 


Three example 
jobs are shown in Figure 2 to demon- 


strate how two tasks can share an object that was not 
known to the programmers 
at the time the tasks were 


developed. 
Both Job' A' and Job 'B' exist within the en- 


vironment 
of the 'Root Job' that forms the foundation 
of 


all iRMX 86 systems. 
Each job possesses a directory 
in 


which tasks may catalog the name of an object. Sema- 
phore 'RS', for example, is access able by all tasks in the 
system, because 
its name is cataloged 
in the directory 


of the Root Job. Mailbox 
'AN' can be used to transfer 


objects between Tasks 'A2' and 'A3' because 
its token 


is accessable 
in the object directory 
for Job 'A' 


Table 1 lists the major functions of the iRMX 86 Nucleus 
that manage 
system 
processes. 


8 
MAILBOX 
& 


OBJECT 
DIRECTORY 


MAilBOX 
AM 
MAILBOX 
AN 
TASK 
A3 


OBJECT 
DIRECTORY 


MAILBOX RM 1Q!!...A 
SEMAPHORE 
RS JQlUl 


TASK 
B2 


Memory Management 


Each job in an iRMX 86 System defines the amount of 
the one megabyte 
of addressable 
memory 
to be used 


by its tasks. The iRMX 86 Operating 
System manages 


system memory and allows jobs to share this critical re- 
source 
by providing 
another 
object type: segments. 


Segments 
are contiguous 
pieces of memory, 
between 


16 Bytes and 64K Bytes in length, that exist within the 
environment 
of the job in which they were created. Seg- 


ments form the fundamental 
piece of system 
memory 


used for task stacks, data storage, system buffers, loading 
programs from secondary 
storage, passing information 


between 
tasks, etc. 


inter 


System 
Call 
Function 
Performed 


RQ$CREATE$JOB 
Creates an environment for a number of tasks and other objects, as well as creating an 
initial task and its stack. 


RQ$DELETE$JOB 
Deletes a job and all the objects currently defined within its bounds. All memory used 
is returned to the job from which the deleted job was created. 


RQ$OFFSPRING 
Provides a list of all the current jobs created by the specified job. 


RQ$CATALOG$OBJECT 
Enters a name and token for an object into the object directory of a job. 


RQ$UNCATALOG$OBJ ECT 
Removes an object's token and its name from a job's object directory. 


RQ$LOOKUP$OBJECT 
Returns a token for the object with the specified name found in the object directory of 
the specified job. 


RQ$GET$TYPE 
Returns a code for the type of object referred to by the specified token. 


RQ$CREATE$MAILBOX 
Creates a mailbox with queues for waiting tasks and objects with FIFO or PRIORITY 
discipline. 


RQ$DELETE$MAILBOX 
Deletes a mailbox. 


RQ$SEND$MESSAGE 
Sends an object to a specified mailbox. If a task is waiting, the object is passed to the 
appropriate task according to the queuing discipline. If no task is waiting, the object is 
queued at the mailbox . 


RQ$RECEIVE$MESSAGE 
.Attempts to receive an object token from a specified mailbox. The calling task may 
choose to wait for a specified number of system time units if no token is available. 


RQ$DISABLE$DELETION 
Prevents the deletion of a specified object by increasing its disable count by one. 


RQ$ENABLE$DELETION 
Reduces the disable count of an object by one, and if zero, enables deletion of that 
object. 


RQ$FORCE$DELETE 
Forces the deletion of a specified object if the disable count is either 0 or 1. 


RQ$CREATE$TASK 
Creates a task with the specified priority and stack area. 


RQ$DELETE$TASK 
Deletes a task from the system, and removes it from any queues in which it may be 
waiting. 


RQ$SUSPEND$TASK 
Suspends the operation of a task. If the task is already suspended, its suspension 
depth is increased by one. 


RQ$RESUME$TASK 
Resumes a task. If the task had been suspended multiple times, the suspension depth 
is reduced by one, and it remains suspended. 


RQ$SLEEP 
Causes a task to enter the ASLEEP state for a specified number of system time units. 


RQ$GET$TASK$TOKENS 
Gets the token for the calling task or associated objects within its environment. 


RQ$SET$PRIORITY 
Dynamically alters the priority of the specified task. 


RQ$GET$PRIORITY 
Obtains the current priority of a specified task. 


RQ$CREATE$REGION 
Creates a region, with an associated queue of FIFO or PRIORITY ordering discipline. 


RQ$DELETE$REGION 
Deletes the specified region if it is not currently in use. 


RQ$ACCEPT$CONTROL 
Gains control of a region only if the region is immediately available. 


RQ$RECEIVE$CONTROL 
Gains control of a region. The calling task may specify the number of system time 
units it wishes to wait if the region is not immediately available. 


RQ$SEND$CONTROL 
Relin!:1uishescontrol of a region. 


RQ$CREATE$SEMAPHORE 
Creates a semaphore. 


RQ$DELETE$SEMAPHORE 
Deletes a semaphore. 


RQ$SEND$UNITS 
Increases a semaphore counter by the specified number of units. 


RQ$RECEIVE$UNITS 
Attempts to gain a specified number of units from a semaphore. If the units are not 
immediately available, the calling task may choose to wait. 


inter 


The example 
in Figure 
2 also demonstrates 
when in- 
formation 
is shared between Tasks 'A2' and 'A3'; 'A2' 
only needs to create a segment, 
put the information 
in 
the memory allocated, 
and send it via the Mailbox 'AM' 
using the RQ$SEND$MESSAGE 
system call (see Table 
1).Task 'A3' would get the message 
by using the RQ$ 
RECEIVE$MESSAGE 
system call. The Figure also shows 
how the receiving task could signal the sending task by 
sending 
an acknowledgement 
via the second Mailbox 


'AN'. 


Each job is created with both maximum 
and minimum 


. limits set for its memory 
pool. Memory 
required 
by all 
objects 
and resources 
created 
in the job is taken from 
this pool. If more memory 
is required, 
a job may be al- 
lowed to borrow memory from the pool of its containing 
job (the job from which it was created). 
In this manner, 


initial jobs may efficienty 
allocate 
memory to jobs they 
subsequently 
create, without 
exactly knowing their re- 
quirements. 


The iRMX 86 Operating 
System supplies other memory 
managment 
functions to search specific address ranges 
for available memory. The System performs this search 
at system initialization, 
and can be configured 
to ignore 
non-existent 
memory 
and addresses 
reserved 
for I/O 
devices 
and other application 
requirements. 


Table 2 lists the major system calls used to manage the 
system 
memory. 


Interrupt Management 


Real-time 
systems, 
by their 
nature, 
must respond 
to 
asynchronous 
and unpredictable 
events quickly. 
The 
iRMX 86 Operating System uses interrupts and the event- 
driven nucleus described earlier to give real-time response 
to events. 
Use of a pre-emptive 
scheduling 
technique 
ensures 
that the servicing 
high priority 
events always 
take precedence 
over other system 
activities. 


The iRMX 86 Operating 
System gives applications 
the 
flexibility 
to optimize 
either interrupt 
response 
time or 
interrupt response capability by providing two tiers of In- 
terrupt 
Management. 
These two distinct tiers are man- 
aged by Interrupt 
Handlers 
and Interrupt 
Tasks. 


Interrupt 
Handlers are the first tier of interrupt service. 


For small, simple functions, 
interrupt handlers are often 
the most efficient means of responding to an event. They 
provide faster response 
than interrupt 
tasks, but must 
be kept simple since interrupts (except the iAPX 86 and 
88 non-maskable 
interrupt) are masked during their exe- 
cution. When extended 
interrupt service is required, 
in- 
terrupt 
handlers 
"signal" 
a waiting 
interrupt 
task that, 


in turn, performs 
more complicated 
functions. 


Interrupt Tasks are distinCt tasks whose priority is associ- 
ated with a hardware interrupt level. They are permitted 


to make any iRMX 86 system call. While an interrupt task 
is servicing 
an interrupt, 
interrupts 
of lower priority are 


not allowed to pre-empt 
the system. 


Table 3 shows the iRMX 86 System Calls provided 
to 


manage 
interrupts. 


Figure 3 illustrates 
how the iRMX 86 Interrupt 
System 


may be used to output strings of characters 
to a printer. 


In the example, a mailbox named 'PRINT' 
is used by all 


tasks in the system to queue messages 
to be printed . 


Application tasks put the characters in segments that are 
transmitted 
to the printer 
interrupt 
service task via the 


PRINT Mailbox. Once printing is complete, the same inter- 
rupt task passes the messages on to another application 
via the FINISHED Mailbox so that an operator message 
can be displayed. 


CALL 
TO 
RQSRECEIVE 
SMESSAGE 


CALL 
TO 
RCSSENDS 
MESSAGE 


The Basic I/O System (BIOS) provides the direct access 
to I/O devices 
needed 
by real-time 
applications. 
The 


BIOS allows I/O functions to overlap other system func- 
tions. In this manner, application 
tasks make asynchro- 


nous calls to the iRMX 86 BIOS, and proceed to perform 
other activities. When the I/O request must be completed 
before an application 
can continue, 
the task waits at a 


mailbox 
for the result of the operation. 


Some system calls provided 
by the BIOS are listed in 


Table 4. 


The Basic I/O System communicates 
with peripheral de- 


vices through device drivers. These device drivers provide 
the System with four basic functions 
needed to control 


and communicate 
with devices: Initialize I/O, Finish I/O, 


Queue I/O, and Cancel I/O. Using the device driver in- 
terface, users of non-standard devices may write custom 
drivers 
compatible 
with the 1/0 System. 


System 
Call 
Function 
Performed 


RQ$CREATE$SEGMENT 
Dynamically allocates a memory segment of the specified size. 


RQ$DELETE$SEGMENT 
Deletes the specified segment by deallocating the memory. 


RQ$GET$POOL$ATIRIBUTES 
Returns attributes such as the minimum and maximum, as well as current size of 
the memory in the environment of the calling task's job. 


RQ$GET$SIZE 
Returns the size (in bytes) of a segment. 


RQ$SET$POOL$MIN 
Dynamically changes the minimum memory requirements of the job environment 
containing the calling task. 


System 
Call 
Function 
Performed 


RQ$SET$INTERRUPT 
Assigns an interrupt handler and, if desired, an interrupt task to the specified interrupt 
level. Usually the calling task becomes the interrupt task. 


RQ$RESET$INTERRUPT 
Disables an interrupt level, and cancels the assignment of the interrupt handler for that 
level. If an interrupt task was assigned, it is deleted. 


RQ$GET$LEVEL 
Returns the number of the highest priority interrupt level currently being processed. 


RQ$SIGNAL$INTERRUPT 
Used by an interrupt handler to signal the associated interrupt task that an interrupt has 
occurred. 


RQ$WAIT$INTERRUPT 
Used by an interrupt task to SLEEP until the associated interrupt handler signals the 
occurrence of an interrupt. 


RQ$EXIT$INTERRUPT 
Used by an interrupt handler to relinquish control of the System. 


RQ$ENABLE 
Enables the hardware to accept interrupts from a specified level. 


RQ$DISABLE 
Disables the hardware from accepting interrupts at or below a specified level. 


System Call 
Function 
Performed 


RQ$A$ATIACH$FILE 
Creates a Connection to an existing file. 


RQ$A$CHANGE$ACCESS 
Changes the types of accesses permitted to the specified user(s) for a specific file. 


RQ$A$CLOSE 
Closes the Connection to the specHied file so that it may be used again, or so that 
the type of access may be changed. 


RQ$A$CREATE$DIRECTORY 
Creates a Named File used to store the names and locations of other Named Files. 


RQ$A$CREATE$FILE 
Creates a data file with the specified access rights. 


RQ$A$DELETE$CONNECTION 
Deletes the Connection to the specified file. 


RQ$A$GET$FILE$STATUS 
Returns the current status ofa specified file. 


RQ$A$OPEN 
Opens a file for either read, write, or update access. 


RQ$A$READ 
Reads a number of .bytes from the current position in a specified file. 


RQ$A$SEEK 
Moves the current data pointer of a Named or Physical file. 


RQ$A$WRITE 
Writes a number of bytes at the current position in a file. 


RQ$WAIT$IO 
Synchronizes a task with the 1/0 System by causing it to wait for 1/0 operation 
results. 


inter 


The iRMX 86 Operating 
System includes 
a number of 


device 
drivers 
to allow 
applications 
to use standard 


USART serial communication 
devices, 
multiple 
CRTs 


and keyboards, 
bubble 
memories, 
diskettes, 
disks, 
a 


Centronics-type 
parallel 
printer, 
and many of Intel's 


iSBC and iSBX™ device controllers 
(see Table 9). If an 


application 
requires use of a non-standard 
device, users 


need only write a device driver to be included 
with the 


BIOS, and access 
it as if it were part of the standard 


system. 
For most random-access 
devices, 
this job is 


further 
simplified 
by using standard 
routines 
provided 


with the System. Use of this technique 
ensures that ap- 
plications 
can remain device independent. 


The iRMX 86 Terminal Support provides line editing and 
terminal control capabilities. 
The Terminal Support com- 


municates 
with devices through 
simple drivers that do 


only character 
I/O functions. 
Dynamic 
terminal 
recon- 


figuration 
is provided so that attributes such as terminal 


type and line speed may be changed without modifying 
the application 
or the Operating 
System. Dynamic con- 
figuration 
may be typed in, generated 
programmatically 


or stored in a file and copied to a terminal I/O connection. 


The iRMX 86 Terminal Support provides automatic trans- 
lation of control characters to specific control sequences 
for each terminal. 
This translation 
enables applications 


using standard 
control characters 
to function 
with non- 
standard terminals. The translation requirements for each 
terminal 
can be stored in terminal 
description 
files and 


copied to a connection, 
as described 
above. 


DISK 110 PERFORMANCE 


Table 5 shows iRMX 86 performance 
obtained using the 


iSBC 215 Winchester 
Disk and iSBX 218 Diskette Con- 


trollers 
under the specified 
conditions. 


Each device driver can be used to interface to a number 
of separate 
and, in some cases, different 
devices (See 


Figure 4). The iSBC 215 Device Driver, supplied with the 
system, is capable of supporting the iSBC 215 Winchester 
Disk Controller, 
the iSBC 220 SMD Disk Controller, 
and 


the iSBX 218 Flexible 
Disk Controller 
(when mounted 


on an iSBC 215 board). Each device controller 
may, in 


turn, control a number of separate device units. In addi- 
tion, each driver may control 
a number 
of like device 


controllers. This capabilify allows the use of large storage 
systems with a minimum 
of I/O system code to write or 


maintain. 


EXTENDED 
I/O SYSTEM 


The iRMX 86 Extended I/O System (EIOS) adds a number 
of I/O management 
capabilities 
to simplify 
access 
to 


files. Whereas 
the BIOS provides 
users with the basic 


system calls needed for direct management 
of I/O re- 


sources, many users prefer to have the system perform 
all the buffering and synchronization 
of I/O requests auto- 


matically. The EIOS allows users to access I/O devices 
without having to write procedures 
for buffering 
data, or 


to specify particular devices with constant device names. 


By performing 
device buffering automatically, 
the iRMX 


86 ErOS optimizes accesses to disks and other devices. 
Often, when an application task asks the System to READ 
a portion ofa file, the System is able to respo'1d immedi- 
ately with the data it has read in advance of lne request. 
Similarly, 
the EIOS will not delay a task for writing data 


to a device unless it is specifically 
told to, or if its output 


buffers 
are filled. 


Logical file and device names are provided by the EIOS 
to give applications 
complete 
file and device indepen- 


dence. Applications 
may send data to the 'line printer' 


(:LP:) without needing to know which specific device will 
be used as the printer. This logical name may, in fact, 
not be a printer 
at all, but it could be a disk file that is 


later scheduled 
for printing. 


The EIOS uses the functions 
provided 
by the BIOS to 


synchronize 
individual I/O requests with results returned 


by device drivers. Most EIOS system calls are similar to 
the BIOS calls, except that they appear to suspend the 
operation 
of the calling task until the I/O requests 
are 


completed. 


Average 


Character 
Throughput 


Function 
Bytes 
per Second" 


Winchester 
Disk 
Diskette 


Single 
File Read 
42,000 
15,800 


Two File Read 
36,800 
5,700 
(Same 
Device) 
• 


Single 
File Write 
23,800 
5,400 


Two File Write 
36,200 
6,900 
(Different 
Devices) 


ReadlWrite 
Two Files 
38,900 
6,000 
(Different 
Devices) 


• These measurements 
were made in the following environment 


Entire iRMXTM86 operating system and application code and data 
located in on·board RAM of a 8-MHz iSBC'" 86/30 Single Board 
Computer. Named files, each with a file size of 128 KBytes, were 
used with a device and volume granularity of 1 KBytes and six 1 
KByte buffers. The disk interleave factor was 2. The iSBC 215 
Winchester Controller was attached to two 20-Mbyte drives, and 
supported the iSBXTM218 Disklltte Controller that, in turn, was at- 
tached to two double density 8" diskette drives. This performance 
is, to a large part, restricted by the mechanical speed of the devices. 
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File Management 


The iRMX 86 Operating 
System provides three distinct 


types of files to ensure efficient management 
of both pro- 


gram and data files: Named Files, Physical 
Files, and 


Stream Files. Each file type provides access to 1/0 de- 
vices through 
the standard 
device 
drivers 
mentioned 


earlier. The same device driver is used to access physical 
and named files for a given device. 


Named files allow users to access information on second- 
ary storage by referring to a file with its ASCII name. The 
names of files stored on a device are stored in special 
files called 
directories. 
As directories 
are themselves 


named files, the iRMX 86 File System allows directories 
to contain the names of other directories. 
Figure 5 illus- 
trates the resulting hierarchical 
file structure. This struc- 


ture is useful for isolating 
file names to particular 
user 


applications, 
and for tailoring system data to the require- 


ments of users and applications sharing storage devices. 
Using different 
branches on the directory tree, different 


users do not have to coordinate 
in naming their files to 


ensure 
unique 
names. 


Whenever 
a request is made involving 
a file name, the 


System will search the appropriate 
directory 
in order to 


find the necessary 
information 
about the file's size, ac- 


cess rights, and specific location on the storage device. 


The iRMX 86 BIOS uses an efficient 
format for writing 


the directory 
and data information 
into secondary 
stor- 


age. This standard 
iRMX 86 format 
is fully compatible 


with the ISO Media standard, 
and other Intel systems 


such as the iRMX 88 Operating 
System. This structure 


enables the system to directly access any byte in a file, 
often without having to do additional 110to access space 
allocation information. The maximum size of an individual 
file is 232 (4.3 billion) bytes. 


The hierarchical 
file structure 
is provided to isolate and 


organize 
collections 
of named files. To give operators 


fast and simple access to any level within the file tree, 
an ATIACHFILE 
command 
is provided. This command 


allows operators 
to give a logical name to a point in the 


tree so that a long sequence 
of characters 
need not be 


typed each time a file is referred 
to. 


____ I = DIRECTORY 


/\ 
= NAMED 
~ 
OATAFllE 


Access 
to each Named 
File ls protected 
by the rights 


assigned 
to each user by the owner of the file. Rights 


to read, append, update, and delete may be selectively 
granted to other users of the system. 
In general, 
users 
of Named Files are classified into one of three categories: 
User, Group, 
and World. 
Users and Groups 
are used 


when different programmers and programs need to share 
information 
stored in a file. The World classification 
is 


used when rights are to be granted 
to all w~o can use 


the system. 


Physical 
Files allow 
more direct 
device 
access 
than 


Named Files. Each Physical File occupies an entire de- 
vice, treated as a single stream of individually accessable 
bytes. No access control 
is provided 
for Physical 
Files 


as they are typically used for such applications as driving 
a printing device, translating 
from one device format to 


another, 
driving 
a paper tape device, 
and controlling 


analog 
mechanisms. 


Stream Files provide applications with a method of using 
iRMX 86 file management 
methods 
for data: that does 


not need to go into secondary 
storage. Stream Files act 
as direct channels, 
through 
system memory, 
from one 


task to another. These channels 
are very useful to pro- 


grams, for example, wishing to preserve file and device 
independence 
allowing data sent to a printer one time, 


to a disk file another time, and to another 
program 
on 


a different 
occasion. 


Two utilities are supplied 
with the System to load pro- 


grams and data into system 
memory 
from secondary 


storage 
devices: 


The iRMX 86 Bootstrap 
Loader can be configured 
to 


a size of less than 600 bytes of P(ROM), and is typically 
used to load the initial system from the system disk into 
memory, 
and begin its execution. 


The Application 
Loader is typically used by application 


programs already running in the system to load additional 
programs and data from any secondary 
storage device. 


The Human Interface layer, for example, uses the Appli- 
cation Loader to load the non-resident 
Human Interface 


Commands. The Application Loader is capable of loading 
both relocatable 
and absolute code, as well as program 


overlays. 


The flexibility 
of the interface 
between 
computer 
con- 


trolled 
machines 
and their users often determines 
the 


usability and ultimate success of the machines. Table 12 
lists iRMX 86 Human 
Interface 
functions 
giving 
users 


and applications 
simple access to the file and system 


management 
capabilities described earlier. The process, 


interrupt, 
and memory managment 
functions described 


earlier, are performed automatically for Human Interface 
users. 


Using the multi-terminal 
support provided by the BIOS, 


the iRMX 86 Human 
Interface 
can support 
several si- 


multaneous 
users. The real-time 
nature of the system 


is maintained 
by providing 
a priority for each user, and 


using the event-driven iRMX 86 Nucleus to schedule tasks. 
High-performance 
interrupt response is guaranteed even 


while users interact with various application 
packages. 


For example, 
multi-terminal 
support allows one person 


to be using the iRMX 86 Editor, while another compiles 
a FORTRAN 
86 or PASCAL 86 program, 
while several 
others 
load and access applications. 


Each terminal attached to the iRMX 86 multi-user Human 
Interface is automatically 
associated with a user, a mem- 


ory pool, and an initial program to run when the terminal 
is connected. 
This association 
is made using a file that 


may be changed at any time. Changes are effective the 
next time the system 
is initialized. 


The initial program 
specified 
for each terminal 
can be 


a special application 
program, 
a custom 
Human 
Inter- 


face, or the standard 
iRMX 86 Command 
Line Inter- 


preter (CLI). For example, 
you may choose to use the 


Microsoft 
Basic Interpreter 
as this initial program. After 


system start-up, each terminal user would be able to run 
the interpreter 
without 
asking for it to be loaded. 
From 


the BASIC interpreter an operator, for example, could run 
a data collection 
program, 
written 
in BASIC, that com- 


municates with several laboratory instruments, and prints 
charts and reports based on certain test results. When 
finished entering, changing, or running a BASIC program, 
the terminal 
would remain in BASIC for the next user. 


Specifying 
an application 
program as a terminal's 
initial 


program makes the interface between operators and the 
computer system much simpler. Each operator need only 
be aware of the function 
of a particular 
application; 
not 


needing 
to interact 
with any unfamiliar 
functions 
also 


available 
on his application 
system. 


Specifying 
the standard 
iRMX 86 Human Interface 
CLI 


as the initial program 
enables 
users of the terminals 
to 


access all iRMX 86 functions. 
This CLI makes it easy to 


manage iRMX 86 files, load and execute Intel-supplied 
and custom 
programs, 
and submit 
command 
files for 


later execution. 


Real-Time 
Execution 


Function 
Time (msec) 


SUSPEND 
TASK 
0.45 


INTERRUPT 
LATENCY 
0.20 


(to Handler) 
(Max) 


INTERRUPT 
LATENCY 
0.03 


(to Handler) 
(Typical) 


CONTEXT 
SWITCH 
CAUSED 
0.68 


BY INTERRUPT 
(Max) 


SEND 
MESSAGE 
0.30 
(no context 
switch) 
. 


SEND 
MESSAGE 
0.57 
(with context 
switch) 


SEND 
CONTROL 
0.19 
(no context 
switch) 


SEND 
CONTROL 
0.50 
(with context 
switching) 


RECEIVE 
CONTROL 
0.25 
(no waiting) 


Context switch time is the time between executing in the context of 
a task, and the first instruction to execute in the context of another 
task. 


These times were measured using an 8 MHz iSBC"' 86/30 Single Board 
Computer with the standard configuration supported by the Precon- 
figured System, and all program and data stored in on-board dynamic 
RAM. 
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FLEXIBILITY 


PERFORMANCE 
FEATURES 


The iRMX 86 Operating 
System is well suited to serve 


the demanding 
needs of real-time applications executing 


on complex microprocessor 
systems. The iRMX 86 Sys- 


tem also provides 
many tools and features 
needed by 


real-time system developers 
and programmers. 
The fol- 
lowing sections describe features useful in both the de- 
velopment and execution environments. 
The description 


of each feature outlines the advantages 
given to hard- 


ware and software 
engineers 
concerned 
with overall 


system 
cost, expandability 
with custom 
and industry 


standard 
options, 
and long-term 
maintenance 
of iRMX 


86-based systems. The development 
environment 
fea- 


tures also describe 
the ease with which the iRMX 86 


Operating System can be incorporated into overall system 
designs. 


REAL-TIME 
PERFORMANCE 


The iRMX 86 Operating 
System is designed to offer the 


high performance, 
multi-tasking 
functions 
required 
by 


real-time systems. Designers can make use of the latest 
VLSI devices such as the 8087 Numeric 
Processor 
Ex- 
tension, 
and the 80130 Operating 
System 
Firmware 


CQmponent 
to improve their system cosUperformance 


ratio, or the iMMX'" 
800 MULTIBUS® Message Exchange 


LANGUAGE 


DEVELOPMENT 
TOOLS 
STRUCTURED 
DESIGN 


software package to divide and coordinate various system 
activities 
among multiple 
processors. 
Typical iRMX 86 


system performance characteristics are shown in Table 6. 


Many real-time systems require high-performance 
oper- 


ation. To meet this requirement, 
all of iRMX 86 (except 


for the Human Interface commands) can be put into zero 
wait-state 
P(ROM). This approach 
eliminates 
the possi- 


bility of disk access times slowing down performance, 
while allowing 
system designers 
to take advantage 
of 


high performance 
memory 
devices. 


CONFIGURABILITY 


The iRMX 86 Operating System is configurable by system 
layer, and by system call within each layer. In addition, 
all the 110 port addresses 
used by the System are con- 


figurable by the user. This flexibility gives designers 
the 


freedom to choose configurations 
of hardware and soft- 


ware that best suit their size and functional requirements. 
Two example 
configurations 
are shown in Figure 6. 


Most configuration 
options are selected 
during system 


design stages. Others may be selected 
during system 


operation. 
For example, the amount of memory devoted 


to queues within a Mailbox can be specified 
at the time 


the Mailbox 
is created. 
Devoting 
more memory 
to the 


Mailbox allows more messages to be transmitted to other 
tasks without having to degrade system performance 
to 


allocate 
additional 
memory 
dynamically. 


The chart shown in Table 7 indicates the actual memory 
size required 
to support 
these different 
configurations 
of the iRMX 86 System. Systems requiring only Nucleus 
level functions 
may require no more than 13 KBytes for 


the Operating 
System (Use of the iAPX 86/30 requires 
only 4K Bytes of RAM). Other applications, 
needing 
110 
management 
functions, may select portions of additional 
layers that fit their needs and size constraints. 


This configurability 
also applies to the Terminal Handler 
and Debugger layers. They need be included only when 
the iRMX 86 Debugger 
is needed (usually only during 
system development) 
or when a serial terminal interface 


is needed 
in a system that otherwise 
doesn't 
need an 


110 System. 


The resources provided by a single processor are often 
not enough to perform certain functions. With the standard 
interfaces provided by the iMMX 800 MULTIBUS Message 
Exchange package, the iRMX 86 Operating System sup- 
ports a loosely-coupled 
multi-processing 
environment. 


Tasks running on one processor may communicate 
with 


tasks running on other processors, 
even if they operate 


under different 
operating 
systems. The iMMX 800 soft- 
ware is capable of sending messages over the MULTIBUS 
to tasks operating 
under either the iRMX 80 8-bit Multi- 


Tasking Executive, the iRMX 88 Executive, or the iRMX 
86 Operatiflg 
System. 
Using this message 
exchange 
mechanism, 
applications may increase their system per- 
formance quite easily, improve overall interrupt response, 
gain access to the iSBC 550 Ethernet 
Controller, 
and 


leave room for future product 
enhancements. 


Many real-time systems must provide a variety of users 
access to system control functions 
and collected 
data. 


The iRMX 86 System provides 
easy-to-use 
support 
for 


applications 
to access multiple terminals. 
It also enables 


multiple 
and different 
users to access different 
applica- 


tions concurrently. 


Figure 7 illustrates 
a typical iRMX 86 application 
simul- 


taneously 
supporting 
multi-terminal 
data collection 
and 


real-time 
environments. 
Shown is a group of terminals 
used by machinists on a shop floor to communicate 
with 


a job management 
program, a building security system 


that constantly 
monitors energy usage requirements, 
a 


system operator console capable of accessing all system 
functions, 
and a group of terminals 
in the Production 


Engineering 
department 
used to monitor job costs while 


deve.loping new device control specifications 
and instruc- 


tions. The iSBC 544 Intelligent 
Terminal 
Interface 
sup- 


ports multiple user terminals 
without degrading 
system 


performance 
to handle character 
110. 


Figure 7. 
Multi-Terminal 
and Multi-User 


Real-Time 
System 


System 
Layer 
Min. ROMabie 
Max. 
Data 
Size 
Size 
Size 


Bootstrap 
Loader 
O.5K 
1.5K 
6K' 


Nucleus 
10.5K 
24K 
2K 


BIOS 
26K 
78K 
1K 


Application 
Loader 
4K 
10K 
2K 


EIOS 
10.5K 
12.5K 
1K 


Human 
Interface 
22K 
22K 
15K 


UDI 
11K 
11K· 
0 


Terminal 
Handler 
3K 
3K 
O.3K 


Debugger 
28.5K 
28.5K 
1K 


Human 
Interface 
Commands 
116K 


Interactive 
Configuration 
Utility 
308K 


The iRMX 86 Operating 
System provides three means 
of extensions. 
This extendability 
is essential for support 


of OEM and volume end user value added features. This 
ability is provided by: user-defined operating system calls, 
user-defined 
objects (similar to Jobs, Tasks, etc.), and 
the ability to add functions 
later in the product life cycle. 
The modular, 
layered structure 
of the System easily fa- 


cilitates 
later additions 
to iRMX 86 applications. 
User- 
defined 
objects are supported 
by the functions 
listed in 


Table 8. 


Using standard 
iRMX.86 system calls users may define 


custom objects, 
enabling 
applications 
to easily manip- 
ulate commonly 
used structures 
as if they were part of 
the original 
operating 
system. 


EXCEPTION 
HANDLING 


The System includes predefined 
exception 
handlers for 


typical 
1/0 and parameter 
error conditions. 
The error 


handling mechanism is both configurable and extendable. 


SUPPORT 
OF STANDARDS 


The iRMX 86 Operating System supports the many hard- 
ware and software standards needed by most application 
systems 
to ensure that commonly 
available 
hardware 


and software 
packages 
may be interfaced 
with a mini- 


mum of cost and effort. The iRMX 86 System supports 
the iSBC family of products built on the Intel MULTIBUS 
(IEEE Standard 796), and a number of standard software 
interfaces such as the UDI and the common device driver 
interface 
(See Figure 8). The procedural 
interfaces 
of 


System 
Call 
Function 
Performed 


RQ$CREATE$COMPOSITE 
Creates a custom object built of previously defined objects. 


RQ$DELETE$COMPOSITE 
Deletes the custom object, but not the various objects from which it was built. 


RQ$INSPECT$COMPOSITE 
Returns a list of Token Identifiers for the component objects from which the specified 
composite object is built. 


RQ$ALTER$COMPOSITE 
Replaces a component object of a composite object. 


RQ$CREATE$EXTENSION 
Creates a new type of object and assigns a mailbox used for collecting these objects 
when they are deleted. 


RQ$DELETE$EXTENSION 
Deletes an extension definition. 


intel 


the UDI, a software analogy to the MULTIBUS, are listed 
in Table 10. 


The Operating System includes support for the proposed 
IEEE 80-bit extended 
real-variable 
format of the 8087 


Numeric 
Data Processor, 
the IEEE 796 (MULTIBUS) 
hardware interface, and the Intel Universal Run-time In- 
terface (URI). Other standards 
such as the iMMX 800 


MULTIBUS Message Exchange, and an Ethernet' 
com- 
munication interface, are supported by optional software 
packages 
available 
to run on the iRMX 86 System. 


SPECTRUM 
OF CPU PERFORMANCE 


The iRMX 86 System 
supports 
8086 and 8088 based 


systems directly at a variety of processor clock speeds. 
With the iRMX 286R Operating 
System 
option, 
com- 
pletely compatible 
systems can be built around the iAPX 


286 processor. 
By choosing 
the appropriate 
CPU, de- 
signers 
can select from a wide range of performance 


without 
having to change 
application 
software. 


The iRMX 86 System may be tailored to support specific 
hardware configurations. 
In addition to system memory, 
only an iAPX 86 or iAPX 88 microprocessor, 
an 8259A 


Programmable 
Interrupt Controller, 
and either an 8253 


or 8254 Programmable 
Interval Timer are required. 
In 


addition, 
the iRMX 86 Operating 
System may be used 


to augment the functions of the 80130 Operating System 
Firmware Component that not only provides these hard- 
ware functions, but eliminates tlte need for approximately 
14 KBytes of the iRMX 86 Nucleus code (see Figure 6). 
For systems requiring extended mathematics 
capability, 
an 8087 Numeric 
Data Processor 
may be added to per- 


form these functions up to 100 times faster than equivalent 
software. 
For applications 
servicing 
more than 8 inter- 


rupt sources, 
additional 
8259A's 
may be configured 
as 


slave controllers. 


The iRMX 86 Operating 
System includes device drivers 


to support a broad range of MULTIBUS device controllers. 
The particular boards and types of devices supported are 
listed in Table 9. The device controllers 
all adhere to in- 


dustry 
standard 
electrical 
and functional 
interfaces. 


In addition 
to the on-CPU 
board terminal 
drivers, 
the 


iRMX 86 BIOS includes 
two iSBC board-level 
device 


drivers to support 
multiple 
terminal 
interfaces: 


The iSBC 544 Intelligent 
Four-Channel 
Terminal 


Interface Device Driver provides support for multi- 
ple controllers 
each supporting 
up to 4 standard 


RS232 terminals. 
The iSBC 544 driver takes ad- 


vantage of an on-board 8085 processor to greatly 
reduce the system processor time required for ter- 


minal 
I/O by locally 
managing 
input and output 


buffers. The iSBC 544 firmware 
provided with the 


operating 
system can off-load the system CPU by 


as much as 75%. 


The iSBC 534 Four-Channel 
USART 
Controller 


Device Driver also provides 
support 
for multiple 


controller boards each supporting 
up to 4 standard 


RS232 terminals. 


iSBC@ Device 
Supported 
Devices 
Controller 


iSBC®86,88 
Serial Port to CRT, Parallel Port to 
Centronics-type Printer, Interval 
Timer, and Interrupt Controller 


iSBC®204 
Single Density Diskette 


iSBC®206 
Cartridge-type Hard Disk 


iSBC®208 
Single & Double Density, 
Single & Double Sided, 
8" & 5.25" Diskette 


iSBC®215 
Standard Winchester Disks 


iSBC®220 
Standard Storage Module Disks 


iSBC@254 
Bubble Memory Board 


iSBC®534,544 
4-Channel Serial Ports to CRTs, 
Modems 


iSBXTM218 
Single & Double Density, Single 
& Double Sided, 8" & 5.25" Disk- 
ette (When used on an iSBC®215 
Winchester Controller) 


iSBXTM270 
Black and White CRT's and full 
ASCII keyboards 


Development Environment Features 


The iRMX 86 Operating 
System supports 
the efficient 


utilization 
of programming 
time by providing 
important 


tools for program development. 
Some of the tools neces- 


sary to develop and debug real-time systems are included 
with the Operating 
System. 
Others, 
such as language 


compilers, 
are available from Intel and from leading In- 


dependent 
Software 
Vendors. 


LANGUAGES 


The iRMX 86 Operating 
System supports a group of 31 


standard system calls known as the Universal 
Develop- 


ment Interface (UDI). Figure 8 shows that the additional 
features of this standard interface provide iRMX 86 sys- 
tems the capability 
of using many compilers 
and lan- 


guage translators. 
These include 
the iAPX 86 and 88 


Macro Assembler, 
and the Pascal 86/88, PUM 86/88, 
and FORTRAN 86/88 compilers available from Intel. They 
also include a number of other Intel development 
tools, 


intel 


and language translators and utilities available from other 
software vendors. A subset of the UDI System Calls pro- 
vides another 
standard 
interface 
called the Universal 
Runtime Interface (URI~ The URI calls are those required 
to execute a compiled program, while the full set of UDI 
calls is required 
to run a compiler. 


Memory 
Management: 


DQ$ALLOCA 
TE 


DQ$FREE 


DQ$GET$SIZE* 


DQ$RESERVE$IO$MEMORY* 


File Management: 
DQ$ATIACH 


DQ$CHANGE$ACCESS* 


DQ$CHANGE$EXTENSION 


DQ$CLOSE 


DQ$CREATE 


DQ$DELETE 


DQ$DETACH 


DQ$OPEN 


DQ$GET$CONNECTION$STATUS 
* 


DQ$FILE$INFO* 


DQ$READ 


DQ$RENAME* 


DQ$SEEK 


DQ$TRUNCATE 


DQ$WRITE 


Process 
Management: 


DQ$EXIT 


DQ$OVERLAY* 


DQ$SPECIAL 


DQ$TRAP$CC 


Exception 
Handling: 
DQ$GET$EXCEPTION$HANDLER 


DQ$DECODE$EXCEPTION 


DQ$TRAP$EXCEPTION 


Application 
Assistance: 
DQ$DECODE$TIME 


DQ$GET$ARGUMENT* 


DQ$GET$SYSTEM$IO* 


DQ$GET$TIME* 


DQ$SWITCH$BUFFER 


These standard software interfaces (the URI and the UDI) 
ensure that users of the iRMX 86 Operating System may 
transport their applications to future releases of the iRMX 
86 Operating 
System and other Intel and independent 


vendor software products. The calls available in the URI 
and UDI are shown in Table 10. 


Table 
10. 
URI and UDI System 
Calls 


Function 
Performed 


Creates 
a Segment 
of a specified 
size. 


Returns 
the specified 
segment 
to the System. 


Returns 
the size of the specified 
Segment. 


Reserves 
memory 
to OPEN 
and ATIACH 
files. 


Creates 
a Connection 
to a specified 
file. 


Changes 
the user access 
rights 
associated 
with a file or directory. 


Changes 
the extension 
of a file name 
in memory. 


Closes 
the specified 
file Connection. 


Creates 
a Named 
File. 


Deletes 
a Named 
File. 


Closes 
a Named 
File and deletes 
its Connection. 


Opens 
a file for a particular 
type of access. 


Returns 
the current 
status 
of the specified 
file Connection 


Returns 
data about 
a file Connection. 


Reads 
the next sequence 
of bytes 
from 
a file. 


Renames 
the specified 
Named 
File. 


Moves 
the position 
pointer 
of a file. 


Truncates 
a file. 


Writes 
a sequence 
of bytes to a file. 


Exits from 
the current 
application 
job. 


Causes 
the specified 
overlay 
to be loaded. 


Performs 
special 
110 related 
functions 
on terminals 
with special 
control 
features. 


Captures 
control 
when 
CNTRUC 
is typed. 


Returns 
a pointer 
to the program 
currently 
being 
used to process 
errors. 


Returns 
a short 
description 
of the specified 
error code. 


Identifies 
a custom 
exception 
processing 
program 
for a particUlar 
type of error. 


Returns 
system 
time and date in binary 
and ASCII 
character 
format. 


Returns 
the next argument 
from the character 
string 
used to invoke 
the ap- 


plication 
program. 


Returns 
the name 
of the underlying 
operating 
system 
supporting 
the UDI. 


Returns 
the current 
time of day as kept by the underlying 
operating 
system. 


Selects 
a new buffer 
from which 
to process 
commands. 


The high performance 
of the iRMX 86 Operating System 


enhances the throughput of compilers and other develop- 
ment utilities. Table 11 indicates the average performance 
of typical development 
environment 
functions operating 


in the same configuration 
described 
in Table 5. 


Function 
Average 
Execution 
Time 


Directory Command 
5.3 sec 
(S Format with 25 files) 


Load the COPY Command 
1.2 sec 


Copy a 1K Byte File 
1.0 sec 
(Winchester to Winchester) 


Copy a 16K Byte File 
1.7 sec 


Copy a 64K Byte File 
3.9 sec 
Copy a 1K By1eFile 
1.4 sec 
(Winchester to Diskette) 


Compile PUM 86 
3931pm 


Compile PASCAL 86 
4531pm 
Program 


Certain tools are necessary 
for the development 
of mi- 


crocomputer applications. The iRMX 86 Human Interface 
includes many of these tools as non-resident commands. 
They can be included 
on the system disk of an applica- 
tion system, and brought into memory when needed to 
perform 
functions 
as listed in Table 12. 


Command 
Function 


BACKUP 
Copy directories and files from one 
device to another. 


COpy 
Copy one or more files to one or 
more destination files. 


CREATEDIR 
Create a directory file to store the 
names of other files. 


DIR 
List the names, sizes, owners, etc. 
of the files contained in a directory. 


ATTACHFILE 
Give a logical name to a specified 
location in a file directory tree. 


PERMiT 
Grant or rescind user access to a 
file. 


RENAME 
Change the name of a file. 


SUBMIT 
Start the processing of a series of 
commands stored in a file. 


SUPER 
Change operator's ID to that of the 
System Manager with global access 
rights and privileges. 


Command 
Function 


TIME 
Set the system time-of-day clock. 


VERIFY 
Verify the structure of an iRMXTM86 
Named File volume, and check for 
possible disk data errors. 


The iRMX 86 Operating 
System is designed 
to provide 


OEMs the ability to configure 
for specific 
system hard- 


ware and software 
requirements. 
The Interactive 
Con- 


figuration 
Utility (ICU) builds iRMX 86 configurations 
by 


asking appropriate 
questions 
and making 
reasonable 


assumptions. 
It runs on either an Intellec® Series III De- 


velopment System or iRMX 86 System supporting the UDI 
and a hard disk. Table 13 lists the hardware and support 
software 
requirements 
of different 
iRMX 86 develop- 


ment system environments. 


Intellec'" Series III: 
MDS 313 PUM 86/88 Compiler 
One hard disk and one diskette drive 


iRMXTM86 Preconfigured System 


iRMXTM860 Utility 
iRMXTM863 PUM 86/88 Compiler 
iSBC'" 957B Monitor 
448K By1esof RAM 
5M By1eOn-Line Storage and one double-density 


diskette drive 


SYSTEM 86/330 Microcomputer System 


Basic configuration 


Figure 9 shows one of the many screens displayed during 
the process of defining a configuration. 
It shows the ab- 


breviations 
for each choice on the left, a more complete 


description 
with the range of possible 
answers 
in the 


center, 
and the current (sometimes 
default) choice on 


the right. The bottom of the screen shows three changes 
made by the operator (lower case lettering), and a request 
for help on the Exception 
Mode question. 
In response 


to a request 
for help, the ICU displays 
an additional 


screen outlining possible choices and some overall sys- 
tem effects. 


The ICU requests only information 
required 
as a result 
of previous 
choices. 
For example, 
if no Extended 
I/O 


System functions 
are required, the ICU will not ask any 


further questions 
about the EIOS. Once a configuration 


session is complete, the operator may save all the infor- 
mation in a file. Later, when small changes 
are neces- 


sary, this file can be modified. A completely 
new session 


is not required. 


Nucleus 


(ASC) 


(PV) 


(ROO) 


(MTS) 


(OEH) 


(NEH) 


(EM) 


(NR) 


AIISy,Call,(yesfNo} 


Parameter VaHdation (Yes/Nol 
Root Object o,rectory SIZe[0 - OffOhl 


Minimum Transfer Size [0 - OFFFFH] 


Oflaul! Exception Handler (YesiNo/Deb/UseJ 


Name of Ex Handler Object Module 11- 32chsj 


Exception Mode (NeverfProgramlEnvlronlAIIJ 


Nucleus in ROM jYeslNoj 


Enter Changes lAbbreviations 
11;: new-value] : Ase;: N 


:pv:no 
:rod. 48 
:em? 


The iRMX 86 Operating 
System supports three distinct 


debugging 
environments: 
Static, 
Dynamic, 
and Post- 


Mortem. 
While the iRMX 86 Operating 
System 
does 


support 
a multi-user 
Human Interface, 
these real-time 


debugging 
aids are usually most useful in a single-user 


environment 
where modifications 
made to the system 
cannot 
affect other users. 


The static debugging 
aid is the iSBC 957B Monitor (in- 


cluded in the first shipment 
of some iRMX 86 options). 
The Monitor provides 
a basic debugging 
capability 
for 


both system and application 
code. The iRMX 86 Debug- 


ger provides a dynamic system debugging tool for testing 
and debugging 
real-time systems. The Debugger allows 
programmers 
to stop and inspect one task while the rest 


of the system continues to operate. The iRMX 86 Crash/ 
Dump Analyzer enables programmers 
to inspect a sys- 
tem's structure after a problem has caused it to stop nor- 
mal operation. 
Each of these debugging 
facilities 
are 


described 
below. 


The iSBC 957B Monitor can be used either as a stand- 
alone monitor for static debugging 
and system start-up, 
or as a communication 
link to an Intellec Development 


System. A number of PROMs are included along with the 
necessary 
cables to control 
a hardware 
configuration 


such as is pictured in Figure 10. All programs necessary 
for the Intellec system and the target system are included. 
Configuration 
tools for users wishing to support different 


hardware 
configurations 
are also included. 


Debugging 
of any iAPX 86 or 88 application 
is accom- 


plished in an interactive manner via either of the two ter- 
minals shown in Figure 10. If an Intellec Development 
System is not present, all debugging 
instructions 
neces- 


sary to view and modify register and memory contents, 
set execution 
breakpoints 
and provide single instruction 


execution 
are accessable 
from a terminal connected 
di- 


rectly to the iAPX 86 or 88 system. 


P1 


lNTELLEC 


SERIES 


MODEL 
210 


UPP 
CHANNEL 


P2 
SERIAL 
CH l1TTY 


SERIAL 
CH2 


iRMX™ 86 Debugger 


The iRMX 86 Debugger 
runs as part of an iRMX 86 ap- 


plication. 
It may be used at any time during program de- 


velopment, 
or may be integrated 
into an OEM system 


to aid in the discovery of latent errors. The Debugger can 
be used to search for errors in any task, even while the 
other tasks in the system are running. The iRMX 86 De- 
bugger communicates 
with the developer via a terminal 


handler 
that supports 
full line editing. 


System Crash/Dump Analyzer 


The often difficult job of debugging 
real-time applications 


is made 
much simpler 
with the System 
Crash/Dump 


Analyzer. 
The analyzer 
allows program 
developers 
to 


record system memory for later analysis even if the sys- 
tem has halted. This analysis lists such vital information 
as which jobs have active tasks, which system queues 
contain which tasks, and what segments 
contain which 


data. 


The information 
used by the Analyzer 
is obtained 
from 


a copy of iRMX 86 data structures after a fault has caused 
an unexpected 
halt (crash). The processor 
also may be 


halted deliberately 
to perform 
a system 
analysis. 
The 


system 
information 
is created 
by a two-step 
process: 


1. Transferring 
an image of iRMX 86 system 
memory 


to a disk file on an Intellec Series III Microcomputer 
Development 
system. 


2. 
Later printing 
an analyzed 
and formatted 
printout 


description 
of the state of the system. 


Figure 
11 shows a portion 
of a CrashlDump 
Analyser 


display for an iRMX 86 Mailbox. 
The display 
identifies 


the mailbox 
by its token and shows its key attributes. 


This information 
is followed by a list of tokens for objects 


(if any) queued 
at the mailbox. 


II 
11--- ---------- 
- - - ------------ 
----- 
- ---------- 


II 
II 
_IIII'O,t,toI<M=4AM 
PRIORITY 


II 
QUEUE 


11- --------- 
--- 
-------- 
- -- --------------- 
- ---- 


II 


Containing Job 
4840 


TISk_head 
0II0Il 


Object_depth 
3C 


DueIledisciplille 
PAl 
Objectqueue head 
4A83 


NO TASKS 
WAITING 


4B4DJ/4A7FG 
484DJ14A6FG 


484DJ/4A68G 
484DJf4A69G 


The analysis 
displays 
all the mailboxes 
(among other 


things) which exist within each job. Thus a user might 
learn critical 
information 
by observing 
a number of ob- 


jects different 
from that expected. 


Performance 
problems 
can be identified 
under some 


circumstances. 
Noticing that certain mailboxes frequently 


have many objects queued may suggest an increase in 
the high performance 
cache size for the mailbox to im- 


prove its throughput, 
or give the designer 
cause to in- 


vestigate 
the receiving 
task operation 
to see why the 


queue is so large. 


The analyzer automatically 
checks for system inconsis- 


tencies such as corrupted data structures, incorrect object 
types, and stack overflow. Reports of such problems ac- 
company 
the reports on specific 
system objects. 


Some iRMX 86 System 
Calls require parameters 
that 


may change 
during the course of developing 
iRMX 86 


applications. 
The iRMX 86 Operating 
System includes 


an optional set of routines to validate these parameters 
to ensure that correct numeric values are used, and that 
correct object types are used where the System expects 
to manipulate 
an object. For systems based only on the 


iRMX 86 Nucleus, these routines may be removed to im- 
prove the performance and code size of the System once 
the development 
phase is completed. 


A ready-to-run, 
multi-user, 
Preconfigured 
System is in- 


cluded in each iRMX 86 KIT. Its configuration 
supports 


the full complement 
of devices shown in Figure 12. The 


shaded area of the Figure represents the minimum hard- 
ware required by the start-up system. Other combinations 
of the devices, 
up to the full compliment 
shown, 
that 


support additional on-line storage are also possible. The 
Preconfigured System includes all iRMX 86 System Calls 
and the complete Universal Development Interface (UDI). 
The UDI supports Intel High-Level Languages and many 
applications 
available from Intel and many Independent 


Software 
Vendors. 


The Preconfigured 
System is intended 
to aid the initial 


use of iRMX 86 features. Any 808lH>ased system currently 
supporting 
an iRMX 86 environment 
with a double den- 


sity diskette may simply plug in the start-up system and 
run. Further, this start-up system may be used to run the 
ICU (if a Winchester 
disk is attached 
to the system) to 


develop custom configurations 
such as those pictured 


in Figure 7. As shipped, 
the Human Interface 
supports 


a single user terminal. However, the Preconfigured 
Sys- 


tem user terminal 
file may be altered easily to support 


from two to five users. 


This System is also available as a separate product (order 
code RMX 86PC E) for those iRMX 86 users that do not 
require the ability to tailor their system to custom hard- 
ware and software configurations. 
The SYSTEM 86/300 


Family of Microcomputer 
Systems 
also provide 
users 


immediate access to programming 
tools and system ap- 


plications 
with a ready-to-Ioad 
preconfigured 
iRMX 86 


Operating 
System. 


iRMX 86 Development 
Utilities 


Package 
including 
the iAPX 86 and 88 


Linker, 
Locater, 
Macro Assembler, 


Librarian, 
and the iRMX 86 Editor 


PASCAL 86/88 Compiler 


Supported Software Products 


iRMX 286R 
iRMX 86-compatible 
Operating 
System 
extension 
for iAPX 80286 


iRMX 862 


iRMX 863 


iRMX 864 


iMMX800 


FORTRAN 
86/88 Compiler 


PUM 86/88 Compiler 


TX Screen-oriented 
Editor 


MULTIBUS 
Message 
Exchange 
soft- 


ware package 
for iRMX 80, 86, and 88 


application 
systems 


Support 
Package 
for iAPX 86/30 and 


88/30 Operating 
System 
Processors 


Supported Hardware Products 


COMPONENTS 


iAPX 86 and 88 Microprocessors 


iAPX 286 Microprocessors 
(with iRMX 286R) 


8087 Numeric 
Data Processor 
Extension 


iAPX 86/30 (80130) Operating 
System 
Firmware 


Component 
(with iOSP 86) 


8253 and 8254 Programmable 
Interval Timers 


8259A Programmable 
Interrupt 
Controller 


8251A USART 


8255 Programmable 
Parallel 
Interface 


iSBC® MULTIBUS® 
BOARD AND SYSTEM PRODUCTS 


iSBC 86/12A, 
86/05, 86/14, 86/30, 88/25, and 88/40 


Single 
Board Computers 


iSBC 286/10 Single Board Computer (With iRMX 286R) 


iSBC 204 Diskette 
Controller 


iSBC 206 Hard Disk Controller 


iSBC 208 Diskette 
Controller 


iSBC 215 Winchester 
Disk Controller 


iSBC 220 SMD Disk Controller 


iSBC 254 Bubble 
Memory 
System 


iSBC 534 4-Channel 
Terminal 
Interface 


iSBC 544 Intelligent 
4-channel 
Terminal 
Interface 
and 


Controller 
' 


iSBX 218 Diskette 
Controller 
(with iSBC 215) 


iSBX 350 Parallel Port (Centronics-type 
Printer Interface) 


iSBX 351 Serial Communications 
Port 


iSBX 270 CRT, Light Pen and Keyboard 
Interface 


SYSTEM 
86/330 Computer 
System 


SYSTEM 
86/380 Computer 
System 


Available Literature 


The iRMX 86 Documentation 
Set is comprised 
of follow- 
ing reference 
manuals. 
Each is also be available under 


the order numbers 
shown. 


Introduction 
to the iRMX 86 Operating 
System 


(9803124-04) 


iRMX 86 Operator's 
Manual (144523-001) 


Master Index for iRMX 86 Release 5 Documentation 


(145015-001 ) 


Getting 
Started With The Release 5 iRMX'86 
System 


(145073-001) 


iRMX 86 Installation 
Guide (9803125-05) 


iRMX Configuration 
Guide (9803126-05) 


iRMX 86 Nucleus 
Reference 
Manual (9803122-04) 


iRMX 86 Terminal 
Handler 
Reference 
Manual 


(143324-002) 


iRMX 86 Debugger 
Reference 
Manual (143323-002) 


iRMX 86 Basic 1/0 System 
Reference 
Manual 
(9803123-05) 


iRMX 86 Loader Reference 
Manual (143318-002) 


iRMX 86 Extended 
1/0 System 
Reference 
Manual 
(143308-002) 


iRMX 86 Human 
Interface 
Reference 
Manual 


(9803202-003) 


Guide to Writing 
Device Drivers for the iRMX 86 and 


iRMX 88110 Systems 
(142926-004) 


iRMX 86 Programming 
Techniques 
(142982-003) 


User's Guide For The iSBC 957B iAPX 86,88 
Interface 


and Execution 
Package 
(143979-002) 


iRMX 86 Disk Verification 
Utility Reference 
Manual 


(144133-002) 


Runtime 
Support 
Manual for iAPX 86, 88 Applications 


(121776-002) 


iRMX 86 Crash Analyzer 
Reference 
Manual 


(144522-001 ) 


OPTIONAL 
REFERENCE 
MATERIALS 


Edit Reference 
Manual (143587-002) 


Guide to Using iRMX 86 Languages 
(142907-001) 


APPLICATION 
NOTES 


Ap Note 86 - 
iRMX 86 Realtime 
Multitasking 


Operating 
System 


Ap Note 130 - 
Using Operating 
System Processors 
to 


Simplify 
Microcomputer 
Designs 


Introduction 
to the iRMX 86 Operating 
System 


Advanced 
iRMX 86 Operating 
System Concepts 


Contact 
Local Intel Sales Office for details on available 


video-tape 
and slide presentations. 


intel 


ORDERING INFORMATION 


The iRMX 86 Operating 
System 
is available 
under a 


number of different licensing options as noted here. Ex- 
cept for source listings (available on microfiche) all options 
are provided on either single or double density ISIS-for- 
matted diskettes, or on double density iRMX 86-formatted 
diskettes. 
ISIS-format 
diskettes 
may be used on Intel 


Intellec Development Systems. The iRMX 86-format may 
be used on any iRMX 86-based system supporting 
the 


appropriate 
comJjilers and development 
environment. 


The OEM license options listed here allow users to incor- 
porate the iRMX 86 Operating 
System into their appli- 
cations. Each use requires. payment of an Incorporation 
Fee. 


Order Code 
Description 


RMX 86 KIT ARO: 
Single density 
OEM license. 


RMX 86 KIT BRO: 
Double der.sity OEM license. 


RMX 86 KIT ERO: 
Double density 
iRMX 86-Format 


OEM license for use on iRMX 
86-based 
environments. 


Other licensing options include prepayment 
of all future 


incorporation fees, single use rights for a single machine, 
use at a second development site, one-year support serv- 
ice extensions, 
the right to make copies for additional 


development 
systems, 
and source 
listing materials. 


Each option 
includes 
90 days of support 
service 
that 


provides 
a periodic 
NEWSLETIER, 
Software 
Problem 


Report Service, and copies of System updates that occur 
during this period. 
Except for source 
listings, 
all initial 


licenses include the iSBC 957B iAPX 86 and 88 System 
Mo~itor, and a complete set of iRMX 86 Documentation. 


As with all Intel software, purchase of any of these options 
requires the execution 
of a standard 
Intel Master Soft- 


ware License. The specific rights granted to users depend 
on the specific 
option and the License 
signed. 


PRECONFIGURED 
iRMX™ 86 
OPERATING SYSTEM 


• Ready·to·run Preconfigured iRMX™ 86 
Operating System for iSBC® systems 


• Efficient realtime multitasking 
scheduler with 255 priority levels 


• Complete support of 8087 numeric 
processor extension 


• Direct support of independent 
software vendor compilers and 
applications 


• Direct support for Intel on·target 
compilers and development tools 


• Simple program load and debug with 


Bootstrap and Monitor in 2732A 
EPROMs 


• Device drivers included for up to four 


diskettes, serial terminal interface, and 
parallel line printer 


• A complete, high· performance, 
execution engine for UDI applications 


The Intel Preconfigured 
iRMX 86 Operating 
System is a flexible, 
realtime, and mUltitasking 
system which 


is configured 
to run on a low-cost, 
iSBG 86-based hardware 
system. 
The iRMX 86 Operating 
System 
is 


designed 
to provide a structured 
and efficient 
environment 
for many time- and performance-critical 
appli- 


cations 
such as factory automation, 
business data and text processing, 
medical electronics, 
data commu- 


nications 
and process 
control. 
The Preconfigured 
System 
provides 
this environment 
without 
requiring 


specific 
hardware and software 
configurations. 
Based on the UDI software 
interface 
architecture 
for op- 


tional compilers 
and interpreters, 
the iRMX 86 PG System supports 
development 
of sophisticated 
applica- 


tions 
usir"g the target 
hardware. A ready-to-use 
comprehensive 
human interface 
provides 
advanced 
ser- 


vices 
including 
creating 
and maintaining 
a hierarchical 
file 
system, 
entering 
the debug 
monitor 
and 


backing-up 
diskette 
volumes. 


UNIVERSAL 
DEVelOPMENT 
INTERFACE 
IUOI) 


UNIVERSAL 
RUN· TIME 
INTERFACE 
IUAI) 


The 
following 
are lrademat1(s 
of Intel 
Corporation 
and 
may 
be used 
only 
10 describe 
Inlel 
products: 
Inlel, 
CREDIT, 
Index, 
Insite, 
Inlellee, 
Library 
Manager, 
Megachassis, 


Micromap, 
MULTI BUS, PROMPT, 
UP" ,.Scope, 
Promware, 
MeS, 
ICE, iRMX, 
iSBC, iSex, 
MULTIMOOULE 
and leS.lntel 
Corporation 
assumes 
no responsibility 
for the use 01 any 


circuitry 
other 
than CIrcuitry 
embOdied 
in an Inlel 
product. 
No other 
circuli 
patent 
licenses 
are implied. 


The Preconfigured 
iRMX 86 Operating 
System is a 


complete 
set of system 
software 
modules 
that are 


ready-to-run 
in a simple 
MULTIBUS 
system 
con- 


sisting 
of an iSBC 86 computer, 
memory, 
and a 


diskette 
controller 
board. 
All the features 
of the 


iRMX 86 Operating 
System are provided along with 


a bootstrap 
monitor 
to load the system diskette 
in- 


to the system. 


The Preconfigured 
iRMX 86 System provides 
both 


implicit 
and explicit 
management 
of system 
re- 


sources. 
These resources 
include 
the processor's 


time and registers, 
up to one megabyte 
of system 


memory, 
independent 
interrupt 
sources, 
all input 


and output 
devices, 
as well as directory 
and data 


files contained 
on up to four diskettes. 


In applications 
where 
computers 
are required 
to 


perform 
many functions 
simultaneously, 
the iRMX 


86 Operating 
System 
provides 
a multiprogram- 
ming 
environment 
in which 
many 
independent, 
and optionally 
multitasking, 
applications 
may run. 
Each application 
environment 
may be treated sep- 
arately to allow application 
programmers 
the flex- 


ibility 
to 
separately 
manage 
each 
application's 


resources. 
A complete 
description 
of the iRMX 86 


Operating 
System 
can be found 
in the 
iRMX 86 


Data Sheet (Order Number: 
210330). 


User Commands 


The 
iRMX 86 PC System 
provides 
a number 
of 


powerful 
tools 
necessary 
for the development 
of 


microcomputer 
applications. 
They are included 
on 


the system 
disk 
and brought 
into 
memory 
when 


needed to perform 
the functions 
listed 
in Table 1. 


These commands 
are especially 
useful for manag- 


ing user programs 
and data stored 
on diskettes. 


File Management 


The iRMX 86 PC file management 
system 
allows 


users to access 
information 
on diskettes 
by refer- 


ring to a file with 
its ASCII name. The names 
of 


files 
stored 
on a disk 
are catalogued 
in special 


files 
called 
directories. 
As directories 
are them- 


selves named files, the iRMX 86 file system allows 
directories 
to contain 
the 
names 
of other 
direc- 


tories. This leads to a hierarchical 
file structure 
as 
illustrated 
in Figure 2. This structure 
is useful 
for 


isolating 
file names of particular 
applications, 
and 


for tailoring 
the system's 
data to the requirements 


of users and applications 
sharing 
storage devices. 


6 
FilEo 
DIRECTORY 


Command 
Function 


ATIACHDEVICE 
Gives 
a logical 
name to a specific 
disk, 
CRT, or Printer 
device 


BACKUP 
Copy directories 
and files 
from 
one device 
to another 


COPY. 
Copy one or more files 
to one or more destination 
files 


CREATEDIR 
Create 
a directory 
file to store 
the names 
of other 
files 


DATE 
Set the system 
calendar 


DELETE 
Delete 
a file or directory 


DEBUG 
Enter the System 
Monitor 


DETACH DEVICE 
Remove 
a device 
from 
the system 


DIR 
list 
the names, 
sizes, owners, 
etc. of the files 
contained 
in a directory 
FORMAT 
Prepare 
a new diskette 
volume 
for use 


RENAME 
Change 
the name of a file 


RESTORE 
Recreates 
a volume 
saved by BACKUP 


SUBMIT 
Start 
the processing 
of a series 
of commands 
stored 
in a file 


TIME 
Set the system 
time-of-day 
clock 


VERIFY 
Verify the structure 
of an iRMX 86 Named File volume, and check 
for possible 
disk data errors 


Figure 
2 also 
shows 
the 
structure 
of the direc- 
tories 
on the iRMX 86 PC system 
diskette. 
It con- 
tains 
all the programs 
and commands 
that make 


up the iRMX 86 PC System. 
Users may add other 


files 
and 
directories 
anywhere 
in the 
structure. 
Whenever 
an operator 
makes a request to use one 


of these 
files, 
the System 
will 
search 
the appro- 
priate directory 
tree in order to find the necessary 


informati.on 
about 
the 
file's 
size, 
access 
rights, 


and specific 
location 
on the diskette. 
Applications 


may also refer to a specific 
file or group of files by 


specifying 
the directory 
from 
which 
to start 
the 


search. 


Standard 
Interfaces 


The iRMX 86 PC System 
supports 
a group 
of 25 


easy-to-use 
standard 
system 
calls 
known 
as the 


System 
Call 


Memory Management: 


DQ$ALLOCATE 


DQ$FREE 


DQ$GET$SIZE 


File Management: 


DQ$ATIACH 


DQ$CHANGE$EXTENSION 


DQ$CLOSE 


DQ$CREATE 


DQ$DELETE 


DQ$DETACH 


DQ$OPEN 


DQ$R!;:AD 


DQ$RENAME 


DQ$SEEK 


DQ$TRUNCATE 


DQ$WRITE 


Process Management: 


DQ$EXIT 


DQ$G ET$CON N ECTION$ST ATUS 


DQ$OVERLAY 


DQ$SPECIAL 


Exception 
Handling: 


DQ$G ET$EX CE PTiO N$HA NOLE R 


DQ$DECODE$EXCEPTION 


DQ$TRAP$EXCEPTION 


Universal 
Development 
Interface 
(UDI). Figure 
1 


shows 
how 
this 
interface 
provides 
iRMX 
86 


systems 
the capability 
of using 
many compilers 


and language 
translators. 
These include 
the iAPX 


86 and 
88 Macro 
Assembler, 
and 
the 
PASCAL 


86/88, PLiM 86/88, and FORTRAN 86/88 compilers 
available 
from Intel. They also include 
a number of 


other Intel development 
tools, and language 
trans- 


lators 
and 
applications 
available 
from 
indepen- 


dent software 
vendors. 


The standard 
UDI software 
interface 
establishes 
a 


path to future 
Intel software 
products 
and opens 


the door to a host of compilers, 
interpreters, 
and 


application 
programs 
available 
from 
independent 


software 
vendors. 
These UDI calls are easy-to-use 


and are listed in Table 2. A more complete 
list of all 


the 
system 
calls 
provided 
by the 
iRMX 
86 
PC 


System 
can be found 
in the iRMX 86 Data Sheet. 


Table 2. UDI System 
Calls 


Function 
Performed 


Creates 
a segment 
of a specified 
size for use by the application. 


Returns 
the specified 
segment 
to the system. 


Returns 
the size of the specified 
segment. 


Creates 
a connection 
to a specified 
file. 


Changes 
or adds an extension 
to a file name. 


Closes 
the specified 
file connection. 


Creates 
a Named 
File for use by the application. 


Deletes 
a Named 
File. 


Closes 
a Named 
File and deletes 
its connection. 


Opens 
a file for a particular 
type of access. 


Reads the next sequence 
of bytes 
from 
a file. 


Renames 
the specified 
Named 
File. 


Moves 
the current 
position 
pointer 
of a file. 


Truncates 
a file to the specified 
length. 


Writes 
a sequence 
of bytes 
to a file. 


Exits 
form 
the current 
application 
job. 


Returns 
the current 
status 
of the specified 
file connection. 


Causes 
the specified 
overlay 
to be loaded. 


Performs 
special 
I/O related 
functions 
on terminals 
with 
special 
control 


features. 


Returns 
a pointer 
to the program 
currently 
being 
used to process 
errors. 


Returns 
a short 
description 
of the specified 
error code. 


Identifies 
a custom 
exception 
processing 
program 
for a particular 
type 
of error. 


System 
Call 
Function 
Performed 


Application 
Assistance: 


OQ$GET$ARGUMENT 
Returns the next argument from the character string used to invoke the 
application 
program. 


OQ$GET$SYSTEM$ID 
Returns the name of the underlying 
operating 
system supporting 
the 


UOL 


OQ$GET$TIME 
Returns the current 
time of day as kept by the underlying 
operating 


system. 


OQ$SWITCH$BUFFER 
Selects a new buffer from which to process commands. 


Simple System Start-Up 


The iRMX 86 PC system 
includes 
a comprehensive 


Monitor 
and 
Bootstrap 
Loader 
in 
four 
2732A 


EPROMs. 
These 
programs 
have been 
configured 


to 
support 
the 
hardware 
shown 
in 
Figure 
3. As 


shown, 
the Monitor 
is capable 
of communicating 


with 
an 
Intel lee 
Microcomputer 
Development 


System. 
This communications 
link can be used to 


transfer 
programs 
and data 
between 
an iRMX 
86 


System 
and the Intellec 
Development 
System. 


This 
start-up 
system 
provides 
a perfect 
environ- 
ment 
for the development 
and efficient 
execution 


of applications 
programs. 
When 
these 
programs 


require 
different 
I/O devices 
or a different 
software 


configuration, 
they 
can 
be 
moved 
to 
any 
other 


iRMX 86 System 
directly. 
The iRMX 86 PC System 


includes 
a separate 
diskette 
with the complete 
set 


of 
iRMX 
86 multitasking 
system 
calls 
for 
those 


programmers 
requiring 
more function 
than is sup- 


plied 
by the UDI. 


Debugging Aids 


The 
iRMX 
86 
PC 
System 
includes 
a System 


Monitor 
that 
provides 
the capability 
of debugging 


one 
task 
at a time. 
The monitor 
includes 
instruc- 


tions 
for examining 
and modifying 
the contents 
of 


all 8086 and 8087 registers, 
setting 
system 
break· 


points, 
single-stepping, 
examining 
and modifying 


system 
memory, 
executing 
CPU 
110, and 
disas· 


sembling 
program 
instructions. 
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Optional Intel@Software Products 


iRMX 86 
Fully 
configurable 
iRMX 86 Realtime 


Operating 
System 


iRMX 860 
iRMX 86 Development 
Utilities 
Pack- 


age 
including 
the 
iAPX 
86 and 
88 


Linker, 
Locater, and Macro Assembler, 
Librarian, 
and the iRMX 86 Editor 


iRMX 861 
PASCAL 86/88 Compiler 
for execution 


on iRMX 86 Systems 


iRMX 862 
FORTRAN 
86/88 Compiler 
for execu- 


tion on iRMX 86 Systems 


iRMX 863 
PUM 86/88 Compiler 
for execution 
on 


iRMX1l6 
Systems 


iSBC 957B iAPX 
86 System 
Monitor 
and 
Micro- 


computer 
Development 
System 
Com- 


munications 
Link 


Supported Hardware Products 


ISBC@ MULTIBUS@ PRODUCTS 


iSBC 86/12A, 86/14, and 86/30 Single 
Board Com- 


puters 


iSBC 208 Flexible 
Disk Controller 


PERIPHERAL 
DEVICE 


CRT - 
RS232 at 9600 Baud 


Printer - 
Centronics-type 
Parallel 
Interface 


Diskettes 
- 
2 to 
4 Single- 
or 
Double-Density, 
Single- or Double-Sided 


Memory Requirements 


200K Bytes to support 
applications 
less than 16K 


Bytes_ 


384K Bytes 
to support 
Intel's 
PASCAL 
86 Com- 
piler. 


256K 
Bytes 
to 
support 
Microsoft's 
Basic 
Inter- 
preter 
and 
a 32K 
Byte 
user 
program 
and 
data 


space. 


Reference Material 


iRMX 86 Operating 
System 
Data Sheet (210330) 


Getting 
Started 
with the iRMX 86 System 
(144340-001) (Included 
in PC System 
Package) 


Introduction 
to the iRMX 86 Operating 
System 


(9803124-03) 


iRMX 86 Installation 
Guide (9803125-04) 


iRMX 86 Configuration 
Guide (9803126-04) 


iRMX 86 NUCLEUS Reference 
Manual (9803122-03) 


iRMX 86 Terminal 
Handler 
Reference 
Manual 


(143324-01 ) 


iRMX 86 Debugger 
Reference 
Manual (143323-01) 


iRMX 86 Basic I/O System 
Reference 
Manual 


(9803123-04) 


iRMX 86 Loader Reference 
Manual (1433111-01) 


iRMX 86 Extended 
I/O System 
Reference 
Manual 
(143318-001 ) 


iRMX 86 Human 
Interface 
Reference 
Manual 


(9803202-002) 


iRMX 86 System 
Programmer's 
Reference 
Manual 


(142721-003) 


Guide 
to Writing 
Device 
Drivers 
for the iRMX 86 


and iRMX 88 I/O Systems 
(142926-003) 


iRMX 86 Programming 
Techniques 
(142982-002) 


User's 
Guide 
for the iSBC 857B iAPX 86,88 Inter· 


face and Execution 
Package (143979-002) 


iRMX 86 Disk Verification 
Utility 
Reference 
Manual 


(144133-001 ) 


iRMX 86 Pocket 
Reference 
(142861-002) 


Edit Reference 
Manual (143587-001) 


Runtime 
Support 
Manual 
for iAPX 86,88 Applica- 


tions 
(121776-001) 


Guide to Using iRMX 86 Languages 
(143907-001) 


Reference 
material 
may be ordered 
from any Intel 


sales 
representative, 
distributor 
office, 
or 
from 


Intel Literature 
Department, 
3065 Bowers Avenue, 


Santa Clara, CA 95051. 


Training Courses 


Introduction 
to the iRMX 86 Operating 
System 


iRMX 86 I/O System 
Concepts 


The iRMX 86 PC System is provided on a double- 
density, iRMX 86 compatible system diskette (for- 
mat type E). The iRMX 86 PC System is shipped 
with 
a comprehensive 
users' 
manual ("Getting 


Started With The iRMX 86 System), Bootloader and 
Monitor EPROMs, and the complete iRMX 86 Inter- 
face Libraries contained on a second diskette. A 
full year of Intel Support Level 0 (Software Problem 
Report Service) is included. This Intel copyrighted 
system is licensed as a single-use software product 
as defined by Intel's Master Software Licenses. 


Order Code 


RMX86PC E 


Description 


Complete Preconfigured iRMX 
86 Operating System with inter- 
face libraries, bootstrap monitor, 
and user documentation. 


iRMX™ 86 LANGUAGES 
AND UTILITIES 


• Provide full software development 


capability for the OEM's iSBC® 86/88, 
System 86/88 
or iAPX 86/88 
"target" 
systems 


• Newest technology languages 


iRMXTM861-ISO 
PASCAL 


iRMXTM862-ANS 
77 Subset FORTRAN 


iRMXTM863-lntel® 
PLIM 86 


• Compilers optimized to increase 


application performance and decrease 
application size 


• All implement the REALMATH standard 


for consistent and reliable results 
using the iAPX 88/20 
or 86/20 
Numeric 


Data Processors 


• Fully compatible with Intel® Intellec® 


development system language 
products 


• Resident on the iRMXTM86 Real-Time 


Multiprogramming Operation System 


• Programming languages for OEM's to 


pass through to system end-users 


• iRMXTM86 utility software, including 


MACRO ASSEMBLER, LINK, LOCATE, 
LIB and both Screen and Line Oriented 
Editors 


• All languages generate Intel® Universal 


Run-TIME Interface (URI) compatible 
programs in the Intel® Standard Object 
Format (OMF) 


The iRMX™ 86 Languages 
and Utilities products 
provide users of Intel's iAPX 86/88, iSBC@86/88 or System 86/88 
microcomputers 
with full "on-the-target-system" 
development 
capability. 
This allows OEMs to provide their end- 


users with the facility 
to make on-the-spot 
modifications 
and add additional 
capability 
to their applications. 
All 


languages 
generate 
code which is compatible 
with Intel's 
Universal 
Run-Time 
Interface. 
This ensures 
users that 


their application 
system will run on the iRMX 86 or iRMX 88 Operating 
System using any iSBC 86/88 or iAPX 86/88 


or System 86/88 microcomputer 
system supporting 
the Universal 
Run-Time Interface. The iRMX 86 Languages 
and 


Utilities 
products 
are fully compatible 
with Series III Development 
System 
based language 
products. 


intel 


Major features 
of the iRMX 86 Languages 
and Utilities 
and their benefits 
include: 


Target System Development 


OEMs 
may accomplish 
application 
software 
develop- 


ment on their target application 
hardware. This provides 
the greatest 
possible 
utility of the OEM's 
application 


system. Additionally, 
OEMs may provide an entirely new 


dimension 
in flexibility 
- 
reprogrammability 
of his 
system 
by the end-user. 


The iRMX 86 Languages 
run directly 
on the iRMX 86 


Operating 
System. 
This 
reduces 
the user's 
learning 


curve, 
since 
users only need to learn one operating 


system 
interface. 


New Technology Languages 


The iRMX 86 Languages 
provide OEMs with the newest 


programming 
languages 
available. 
iRMX 86 PASCAL 


is fully compatible 
with the proposed 
ISO language 


standard. 
iRMX 86 FORTRAN 
provides the majority of 


the ANS 77 FORTRAN language features, including 
IF- 


THEN-ELSE, 
Zero Case Do-Loops, 
and Direct Access 


1/0. The complex arithmetic 
capability, the only missing 


major feature, 
will be supplied 
in a later release. 


Efficient Application Code 


The iRMX Language 
products are optimized 
to provide 


a maximum 
efficiency 
in object code generation. 
This 


provides 
users 
with the smallest, 
fastest 
programs 


which 
a high level language 
can generate. 


Full Language Compatibility 


The 
iRMX 
86 Language 
products 
are compatible 
in 


three ways. They provide a Universal Run-Time environ- 
ment for application 
programs, 
allow object modules to 


be linked together regardless of compiler used, and are 
fully source and object compatible 
with the Series III De- 


velopment 
System 
language 
products. 


The Universal 
Run-Time 
environment 
allows users to 


create 
their 
application 
software 
without 
regard 
for 


which Intel operating 
system it will run on. This allows 


maximum 
flexibility 
in allowing 
applications 
to easily 


move from one processor 
to another, 
and from one 


operating 
system to another. 


All iRMX 86 Languages 
generate code compatible 
with 


the Intel Object 
Module 
Format (OMF) standard. 
This 


provides 
users with the capability 
to mix languages 
on 


a single application 
system. In this way a user can select 


exactly the right language 
tool for specific 
parts of the 


application 
rather than a project 
as a whole. 


Intel Series III Development 
System languages 
provide 


all of the same benefits described, 
allowing users to de- 
velop their software on a system optimized 
for program 


development 
and then easily move it to the final system 
for test, debug and minor redevelopment. 


Full REALMATH Support 


The iRMX 86 Languages 
support the REALMATH 
float- 
ing point standard. 
This allows 
users of all iRMX 86 


languages 
to access the iAPX 86/20 or iAPX 88/20 Nu- 


meric 
Data Processors 
or iSBC 337 MUL TIMODULE 


board. These numeric processors 
offer over 100 times 


greater performance 
than comparable 
software-imple- 


mented algorithms, 
and reduce the system memory re- 


quirements 
by at least 16 KB. The REALMATH standard 


(proposed 
IEEE standard) 
provides 
universal 
consist- 


ency in results of numeric computations. 
The iRMX 86 


Languages 
provide efficient object code generation 
and 


access to the highest performance floating point package 
available 
on microcomputers. 


Complete Set of Languages and Utilities 


The iRMX 86 Languages 
and Utilities 
products 
offer a 


broad 
selection 
of modern, 
highly 
efficient 
language 


products 
and a complete 
set of target 
system 
utility 


software. 


iRMX 86 Languages 
allow you to select the correct lan- 


guage for your application. 


• 
Technical 
- 
FORTRAN 
or PASCAL 


• 
Systems 
Programming 
- 
PUM 


• 
Commercial 
- 
PASCAL 


• 
Size Optimized 
- 
MACRO ASSEMBLER 


The iRMX 86 Utilities provide all necessary software for 
development 
including 
LINK, LOCATE, 
LIB, and both 


Screen 
and Line Oriented 
Editors. 


The iRMX 86 Languages 
allow OEMs to choose from a 


broad spectrum 
of specific language features and "on- 


the-target-system" 
development 
utilities. 


iRMX™ 86 PASCAL (iRMXTM861) 


The iRMX 86 PASCAL compiler 
provides a strict imple- 


mentation 
of the proposed 
ISO language 
standard. 
All 


source 
programs 
are validated 
by the compiler 
to en- 


sure its conformance 
to the standard. 
Many extensions 


intel 


to the language are available which allow PASCAL pro- 
grams 
to be written 
specifically 
for microcomputers. 
Features 
such 
as separate 
module 
compilation 
and 
iAPX 86/20, 88/20 Numeric Data Processor support are 
just a few of the extensions 
available. The ISO standard 


"source 
evaluator" 
can be switched off to accept these 
extensions. 
For more information 
on iRMX 86 PASCAL 
features, see the PASCAL 86/88 Software Package data 
sheet (order number: 
400670) 


iRMXTM 86 FORTRAN 
(iRMXTM 862) 


The iRMX 86 FORTRAN 
compiler 
provides 
users total 
compatibility 
with existing FORTRAN 66 language-gen- 
erated code, plus many new language features provided 
by the FORTRAN 
77 language 
standard. 
These 
new 
features offer FORTRAN programmers 
many new capa- 
bilities, 
including 
"IF-THEN-ELSE", 
random acces 1/0 
and character variables. For a more detailed explanation 
of iRMX 86 FORTRAN, 
see the FORTRAN 86/88 Soft- 
ware Package 
data sheet (order number: 
400630). 


iRMXTM 86 PLIM 
(iRMXTM 863) 


The iRMX 
86 PUM 
compiler 
provides 
users 
with a 
powerful, microcomputer-oriented 
system programming 
language. 
The PUM 80 Language 
was introduced 
in 
1976 by Intel. It was the first microcomputer-oriented, 
block structured, 
high-level 
language 
available. 
Since 
1976, thousands 
of users, shipping 
over millions of mi- 
crocomputer-based 
systems, have generated their soft- 
ware with PUM 80 and PUM 86. 


iRMX 86 PUM 86 is a compatible 
superset 
of PUM 80 
which offers easy portability of software. For more infor- 
mation about iRMX 86 PUM, see the PUM 86/88 Soft- 
ware Package 
data sheet (order number: 
402175). 


iRMXTM 86 Screen 
Editor 
(iRMXTM 864) 


The iRMX 86 Screen Editor provides users with a menu- 
driven, easy-to-Iearn 
Text-Editor. 
The user of the iRMX 
864 Screen 
Editor 
is guided 
through 
all steps of the 
editing process by a menu which is always displayed on 
the CRT screen. 
By keeping 
the menu of commands 
always in view, even infrequent 
users of the Editor are 
able to edit text quickly 
and efficiently. 


The iRMX 864 Screen 
Editor allows users to edit two 
files during a single session. This allows easy transfer- 
ring of text between files and use of existing material in 
the creation 
of new files. 


The 
process 
of creating 
"macros", 
strings 
of com- 
mands which are used frequently, 
is very simple. All you 
have to do is use the commands. 
The iRMX 864 Screen 
Editor remembers 
them and allows you to re-use them 
or store them for future 
use. 


The iRMX 864 Screen 
Editor 
is also fully compatible 


with the iMDX 334 Alter Text Editor. 


iRMX™ 86 EDIT 


The iRMX 86 EDIT program 
provides 
the users with a 


powerful, 
sophisticated, 
line-oriented 
editing 
facility. 


EDIT delivers 
a range of capability 
suitable 
for novice 


users as well as advanced capabilities 
for sophisticated 


users. 
Its key features 
include 
a macro 
processor 


capable 
of creating 
and executing 
complex 
strings 
of 


commands, 
which 
ease the editing 
chore 
as well as 


defining 
blocks 
of texts 
which 
may be included 
any 


where 
in the text file. EDIT offers variable 
command 


sourcing, 
symbolic 
line numbering 
and reference 
by 


symbol. 


The facilities 
of EDIT allow users to create, 
maintain, 


and manipulate 
extensive 
libraries of source code with 


minimal 
effort. 


iRMXTM86 LINK/LOCATE 


The iRMX 86 LINK program 
connects 
object modules 


which have been individually 
compiled 
into a single, re- 
locatable 
object 
module. 
The input object 
code may 


have been produced 
by any Object 
Module 
Format- 


compatible 
compiler. Output object modules may be re- 


combined 
into larger 
object 
modules, 
allowing 
work 


from a large programming 
staff to be easily integrated 
into an application 
system. 


The iRMX 86 LOCATE program 
maps the relocatable 


object 
code 
into the iAPX 86/88 memory 
segments. 


Modules may be targeted for specific memory types. For 
example, 
those portions of the application 
which must 


be (P)ROM resident can be mapped directly to the ap- 
propriate 
address 
range. 


Both iRMX 86 LINK and LOCATE 
provide 
listings 
of 


resultant 
memory and symbol maps for easy reference 


and simplified 
debug. 


iRMX™ 86 LIBRARIAN 


The iRMX 86 LIBRARIAN 
"Library 
manager" 
allows 


creation 
and maintenance 
of object 
module 
libraries. 


These 
libraries 
offer easy collection 
of related 
object 


code 
to reduce 
the overhead 
of maintaining 
many 


separate modules. Users may create new libraries, add 
and delete object modules, 
as well as list the contents 


of the 
library 
and their 
public 
symbols. 
Individual 


modules within the library will automatically 
be included 


in a total 
application 
system 
by the 
iRMX 
86 LINK 


program. 


Required Hardware 


Any iAPX 86/88-based 
or iSBC 86/88-based 
system or 


System 
86/88 
capable 
of 
runnin.g 
the 
iRMX 
86 
Operating 
System, 
Release 4 or later. 


• 
In addition 
to the memory 
required for iRMX 86, the 
language 
and utility products 
will need 140KB 


• 
Two iRMX 86-compatible 
floppy disks or one hard 


disk 


• 
One 8" single-density 
floppy disk drive for distribu- 
tion of software 


Optional Hardware 


iAPX 86/20, iAPX 88/20 or iSBC 337 Numeric Data Pro- 
cessors 
for support 
of the REALMATH 
standard. 


Required Software 


The iRMX 86 Operating 
System, 
Release 4 or later in- 


cluding 
the nucleus, 
basic 
1/0 system, 
extended 
1/0 
system and human 
interface. 


Package 


RMX 860 


RMX 861 


RMX 862 


RMX 863 


RMX 864 


Manual 
Included 


- 
EDIT Manual 
(143587) 


- 
Guide to Using iRMX Languages 
(143907) 


- 
iAPX 86/88 Family Utilities 
(121616) 


- 
Macro Assembly 
Language 
(121627) 


- 
Macro Assembly 
Language 
Opera- 


tions (121628) 


- 
PASCAL 86 User's Guide (121539) 


- 
FORTRAN 
86 User's 
Guide (121570) 


- 
PLIM 86 User's Guide (121636) 


- 
TX User Screen 
Editors 
User's Guide 


(220125) 


The products listed below require the signing of an Intel 
End User Software 
License 
Agreement 
or OEM Soft- 
ware License Agreement. 
All ORO products 
below in- 
clude 1 year of update service. All products 
below are 


support 
catagory 
B. 


iRMXTM 86 Utility 
(EDIT, 
LINK, LOCATE, 
Package 
LIB, MACRO ASSEMBLER) 


8" single-density, 
single-sided 
iRMX 86 compatible 
diskettes 


Update service on 8" single- 
density, 
single-sided 
diskettes 


8" single-density, 
single-sided 
iRMX 86 compatible 
diskettes 


Update service on 8" single- 
density, 
single-sided 
diskettes 


8" single-density, 
single-sided 


iRMX 86 compatible 
diskettes 


Update service 
on 8" single- 


density, 
single-sided 
diskettes 


8" single-density, 
single-sided 
iRMX 86 compatible 
diskettes 


Update service 
on 8" single- 


density, 
single-sided 
diskettes 


8" single-density, 
single-sided 


iRMX 86 compatible 
diskettes 


Update service on 8" single- 
density, 
single-sided 
diskettes 


inter 


iOSP™ 86 


iAPX 86/30 AND iAPX 88/30 SUPPORT PACKAGE 


• Development 
and run-time 
support 
for 


iAPX 86/30 and 88/30 Operating 
System 
Processors 


• Total iRMX™ 86 Operating 
System 


software 
compatibility 


• Extendable 
with iRMX™ 86 Operating 


System 
calls 


• Compatible 
with Intel® PLIM 86/88, 


PASCAL 86/88, FORTRAN 86/88, and 
iAPX 86/88 ASSEMBLER 


• Supports 
(P)ROM or RAM based 


system 


• Complete 
system 
initialization 
aids 


• Complete 
system 
configuration 
aids 


The Intel iOSP 86 Support 
Package for the iAPX 86/30 and 88/30 Operating 
System 
Processors 
contains 
a 
comprehensive 
set of easy-to-use 
tools necessary 
to develop (P)ROM or RAM-based applications 
that use 
the 80130 Operating 
System 
Firmware 
component. 
All of the system 
initialization 
and run-time 
facilities 
are provided 
in libraries 
that may be configured 
to specific 
requirements, 
and linked 
to application 
pro- 
grams 
written 
in either 
iAPX 86 or iAPX 88 Assembler 
or a high level programming 
language 
such as 
PASCAL 86 and PUM 86. The iOSP 86 Package provides 
users with the basic 
initialization 
and interface 
routines 
needed to build application 
software 
based on the fundamental 
operating 
system functions 
of the 
iAPX 86/30 and 88/30 Operating 
System Processors. 
The iOSP 86 Package also enables 
users to add higher 
level 
I/O functions 
from 
the fully 
compatible 
iRMX 86 Operating 
System, 
or to form 
custom, 
real-time 
systems. 


The following 
are trademarks 
at Inlel 
Corporation 
and may be used only 
10 describe 
Inlet 
prOducts: 
Intel, 
CREDIT, 
Index, 
Insite, 
Intellee, 
Library 
Manager, 
Megachassis, 


Micromap, 
MUL TIBUS, 
PROMPT, 
UPI, ,uScope, 
Promware. 
MeS, 
ICE, iAMX, 
iSBC, 
iSBX, 
MUl 
TlMODUlE, 
,OSP and ies. 
Intel Corporation 
assumes 
no responsibility 
lor the use of 
any circuitry 
other 
than circuitry 
embodied 
in an Intel prOduct. 
No other 
circuit 
patent 
licenses 
are implied. 


FUNCTIONAL 
DESCRIPTION 


The iAPX 86/30 and iAPX 88/30 Operating 
System 
Processors 
(OSPs) provide an easy-to-use 
founda- 
tion on which 
many real-time 
applications 
may be 
built. They provide 
the functions 
and system 
sup- 


port 
needed 
to implement 
both simple 
and com- 
plex applications 
that require multiple 
tasks to run 


concurrently 
(see 
Figure 
1). These 
services 
are 
made possible 
by the addition 
of the five new data 


types 
integrated 
into the 80130 Operating 
System 
Firmware 
(OSF) component. 
The 80130 OSF ex- 


tends 
the 
basic 
data types 
of the CPU (integer, 
byte, character, 
etc.) by adding 
new system 
data 


types 
(JOB's, 
TASK's, 
MAilBOX's, 
SEGMENT's, 


and 
REGION's), 
and 
extensive 
timer, 
interrupt, 


memory, 
and error management 
designed 
to give 
real-time 
response 
to 
multitasking 
and 
multi- 
programming 
applications. 
As shown 
in the sec- 
ond half of the figure, other operating 
system func- 


tions 
such 
as mass 
storage 
1/0 
services 
and an 
easy-to-use 
Human 
Interface 
can be added easily, 


by using 
modules 
from 
the 
complete 
operating 
system 
services 
of the iRMX 86 Operating 
System. 


The iOSP 86 Support 
Package provides 
both an in- 
terface 
between 
application 
software 
and 
the 
Operating 
System 
Processors, 
and development 


tools 
designed 
to make the implementation 
and 


initialization 
of real·time, 
multitasking 
systems 
much simpler. 


The 
iOSP 86 Support 
Package 
provides 
system 
developers 
with 
the configuration 
options 
neces- 
sary to tailor 
the iAPX 86/30 and 88/30 Operating 
System 
Processors 
to custom 
applications. 
Using 
the 
Linking 
and 
locating 
facilities 
of either 
an 
Intel 
Intellec 
Development 
System, 
or a suitably 
equipped 
iRMX 86 system, 
the interface 
libraries 
provided 
in the package 
can be added to applica- 


tion 
software 
modules 
to 
form 
easy-to-use 
in- 


itialization 
routines. 
They also form a simple 
inter- 


face 
between 
application 
software 
and 
the 
operating 
system 
primitives 
of 
the 
80130 
OSF 
component. 
The various 
configuration 
options 
in- 
clude: 


Memory and I/O Addressing 


The 
80130 
OSF 
requires 
a 16K 
byte 
block 
of 


memory address space to be reserved for accessing 
internal 
functions. 
The iOSP 86 Support 
Package 
is used to specify 
the base address 
of the 80130 
and the beginning 
of the initialization 
routines. 


All Interrupt 
and Timer management 
of the OSF is 


controlled 
via a reserved 16-byte I/O address 
block 


that may be selected 
by the user. In addition, 
from 


1 to 7 slave 
8259A 
interrupt 
controllers 
can 
be 


specified 
in order to provide the system 
with up to 
57 priority 
interrupt 
sources. 
The OSF baud rate 
generator 
may also 
be configured 
to support 
an 
optional 
terminal 
interface. 


Extending the 80130 OSF 


The 
80130 
OSF allows 
users 
to 
add 
their 
own 
operating 
system 
extensions. 
These 
extensions 


may take advantage 
of the detailed 
and efficient 


intertask 
communication 
and 
synchronization 
primitives 
already 
provided 
by the 80130, andlor 
may utilize 
custom 
functions 
tailored 
to specific 


applications. 
The Support 
Package 
also enables 


users to extend 
the OSF with 
the extensive 
ser- 


vices of Intel's 
iRMX 86 Operating 
System, thereby 


allowing 
applications 
to grow 
without 
having 
to 
change 
or alter application 
software 
already 
writ- 


ten, or having to write other operating 
system 
soft· 


ware. Use of the 80130 with the iRMX 86 Operating 
system 
greatly 
reduces 
the 
amount 
of 
memory 


needed for the iRMX 86 Nucleus 
layer, and enables 


applications 
to take advantage 
of the 
increased 


COMPLEX 
APPLICATION 
SOFTWARE 


COMPILERS 


HUMAN 
INTERFACE 


EIOS 


BASIC 
110 SYSTEM 


iRMX'" 
86 NUCLEUS 


iOSP'" 
86 INTERFACE 
LIBRARIES 


8~7 
I 
8086 
I 


(OPTIONAL) 
OR 
80130 


8088 


performance 
and reduced 
size 
requirements 
in- 
herent in the iAPX 86/30 and 88/30 VLSI Operating 
System 
Processors. 
As each of the services 
pro- 
vided by the 80130 is completely 
iRMX 86-compat- 
ible, applications 
have an automatic 
upward 
path 


to support 
complete 
file systems 
and multiple 
pro- 


cessor 
environments. 


Application Interfaces 


Two interface 
libraries 
are included 
in the iOSP 86 


Support 
Package. The first allows 
programmers 
to 


write 
application 
software 
modules 
in the Com- 


pact 
Model 
of computation 
supported 
by Intel's 


compilers. 
The second 
provides 
an interface 
to 


program 
segments 
written 
in either the Medium or 


Large Models. 


The interface 
libraries 
provide 
the 
means 
of ac- 


cessing 
all 
of 
the 
primitives 
supported 
by the 


Operating 
System 
Processors. 
With this interface, 
and all the memory 
management 
primitives 
of the 


OSPs, applications 
have full access 
to 1M byte of 


memory, 
and all of the addressing 
modes 
of the 


CPU. 


The iAPX 86/30 and 88/30 OSPs allow applications 
to take full 
advantage 
of the Compact, 
Medium, 
and Large models 
of c'omputation 
afforded 
by the 


segment 
model of the CPU's. 


These 
libraries 
are fully 
compatible 
with 
object 


mod u Ies 
prod 
uced 
by 
the 
MAC RO 
86/88 


Assembler, 
and the PASCAL 86/88 and FORTRAN 


86/88 and PLiM 86/88 Compilers. 


Application 
Initialization 


The iOSP 86 Support 
Package provides for the con- 


figuration 
of the system 
Root JOB, and all user ap- 


plication 
JOB's that require initialization 
when the 


system 
is started. 
The user may also specify 
the 


configuration 
of the 
interrupt 
system 
(including 


slave 
8259A 
interrupt 
controllers) 
and the 
clock 


rate 
used 
for 
system 
timing. 
These 
choices 
are 


automatically 
programmed 
into 
the 
various 


devices 
when the system 
is initialized. 


Operating System Calls 


The 80130 OSF performs 
a total 
of 35 operating 


system 
primitives 
all of which are completely 
com· 


patible 
with 
the 
equivalent 
iRMX 
86 Operating 


System 
calls. 
The iOSP 86 Support 
Package 
pro- 


vides 
user·level 
interfaces 
to these 
primitives 
to 


enable applications'to 
create, delete, 
control, 
and 


exchange 
the 
new 
data 
types 
provided 
by the 


80130 OSF. In general, 
these 
interfaces 
allow 
ap- 


plication 
software 
to manage all of the resources 


of an iAPX 86/30 or 88/30 OSP (and an optional 
8087 
Numeric 
Processor 
Extension) 
system 
via 


any of the 35 normal 
Assembly 
Language 
system 


calls shown 
in Figure 2. 


Required Development Hardware 


Use of the iOSP 86 Support 
Package 
requires 
an 


Intel MDS Development 
System 
supporting 
either 


single 
or double 
density 
diskettes, 
or any iRMX 86 


. system 
supporting 
a standard 
floppy 
diskette 


drive 
and the 
iRMX 860 Assembler, 
Linker, 
and 


Locator 
Package. Use of the 80130 requires 
only a 


minimal 
system 
including 
either the iAPX 86/30 or 


88/30 Operating 
System 
Processor, 
and enough 


system 
memory 
to contain 
the 
application 
pro- 


grams and approximately 
2K bytes of initialization 


and 
interface 
software 
provided 
in the 
iOSP 86 


Support 
Package. 


JOB GROUP 


CALL ROSCREATESJOB 


MAILBOX 
GROUP 


CALL ROSCREATESMAILBOX 


CALL ROSOELETESMAILBOX 
CALL ROSSENOSMESSAGE 


CALL ROSRECEIVESMESSAGE 
TASK GROUP 


CALL ROSCREATESTASK 
CALL ROSOELETESTASK 


CALL ROSSUSPENOSTASK 
CALL ROSRESUMESTASK 


CALL ROSSLEEP 


CALL ROSGETSTASKSTOKENS 
CALL ROSSETSPRIORITY 


INTERRUPT 
MANAGEMENT 
GROUP 


CALL ROSSETSOSSEXTENSION 


CALL ROSSETSINTERRUPT 
CALL ROSENTERSINTERRUPT 


CALL ROSEXITSINTERRUPT 


CALL ROSWAITSINTERRUPT 
CALL ROSSIGNALSINTERRUPT 


CALL ROSRESETSINTERRUPT 


CALL ROSENABLE 
CALL ROSOISABLE 


CALL ROSGETSLEVEL 


REGION GROUP 


CALL ROSCREATESREGION 
CALL ROSOELETESREGION 


CALL ROSSENOSCONTROL 


CALL ROSRECEIVESCONTROL 
CALL ROSACCEPTSCONTROL 


SEGMENT 
GROUP 


CALL ROSCREATESSEGMENT 
CALL ROSOELETESSEGMENT 


OELETION CONTROL GROUP 


CALL ROSOISABLESOELETION 


CALL ROSENABLESOELETION 


ERROR CONTROL GROUP 


CALL ROSSETSEXCEPTION 


CALL ROSSIGNALSEXCEPTION 
CALL ROSGETSEXCEPTION 
CALL ROSGETSTYPE 


Each of the ordering options listed below include 
all the necessary initialization 
and interface pro- 
cedures needed to use the iAPX 86/30 and iAPX 
88/30 Operating System Processors. Purchase of 
the iOSP 86 Package requires verification 
of an 
Intel Master Software License. Each package also 
includes an iOSP 86 User's Manual (Document 
Number 143331),and a one-year update service. 


Part Number 


OSP86 A 


Description 


iOSP 86 Support Package con- 
tained on an ISIS-II compat- 
ible, single density diskette. 


iOSP 86 Support Package con- 
tained on an ISIS-II compat- 
ible, double density diskette. 


iOSP 86 Support Package con- 
tained on an iRMX 86 format, 
double density diskette. 


APPLICATION 
NOTE 


I. INTRODUCTION 


The iSBC 957 Intellec-iSBC 
86/12 
Interface 
and 


Execution 
Package 
contains the hardware 
and soft- 
ware required 
to interface 
an iSBC 86/12 
Single 


Board 
Computer 
with an lntellec 
Microcomputer 


Development 
System. The iSBC 957 package 
gives 
the 8086 user the capability 
to develop software 
on 


an lntellec System and then debug this software 
on 


an iSBC 86/12 
board 
using a program 
download 


capability 
and an interactive 
system monitor. 
The 


8086 user has all the capabilities 
of the Intellec sys- 
tem 
at his disposal 
and 
has 
the 
powerful 
iSBC 
86/12 
system 
monitor 
commands 
to 
use 
for 


debugging 8086 programs. 


The iSBC 86/12 
board is an Intel 8086 based proc- 
essor board 
which, 
in addition 
to the processor, 
contains 
32K bytes of dual port RAM, 
sockets for 


up to 16K bytes of ROM/EPROM, 
a serial I/O 


port, 
24 
parallel 
I/O 
lines, 
2 
programmable 


counters, 
9 levels of vectored 
priority 
interrupts, 
and an interface 
to the MUL TIBUS™ 
system bus. 


The iSBC 957 package consists of monitor EPROMs 
for the iSBC 86/12 
board, 
Loader software 
for the 


Intellec system, 
four (4) cable assemblies, 
assorted 


line drivers 
and terminators, 
and signal adapters. 
The iSBC 957 package 
provides 
the capability 
of 


downloading 
and 
uploading 
program 
and 
data 
blocks between an iSBC 86/12 
board and an Intellec 
system. 
In 
addition, 
monitor 
commands 
and 


displays may be input and viewed from the lntellec 
system console. 
The iSBC 957 package, 
when used 


with the iSBC 86/12 
board 
and an Intellec Micro- 


computer 
Development 
System, 
provides 
the user 


with 
the capability 
to edit, 
compile 
or assemble, 


link, 
locate, 
download, 
and 
interactively 
debug 


programs 
for the 8086 processor. 
The iSBC 957 


package 
and the iSBC 86/12 
board 
form 
an ex- 


cellent 
"execution 
vehicle" 
for 
users 
developing 


software 
for 
the 
8086 
processor 
regardless 
of 


whether 
the 
users 
are 
8086 component 
users 
or 


iSBC 86/12 
board users. Using the iSBC 957 pack- 
age 8086 programs 
may be debugged 
at the full 5 


MHz 
speed 
of the 
processor. 
The 
recommended 


hardware 
for the execution 
vehicle is an iSBC 660 


system chassis with an 8 card slot backplane 
and 


power supply, an iSBC 032 32K byte RAM memory 
board, 
the iSBC 957 package, 
and the iSBC 86/12 


board. 


This application 
note will describe 
how the iSBC 
957 package 
may be used to develop 
and 
debug 


8086 programs. 
First 
a description 
of 
the 
iSBC 


86/12 
board 
will be presented. 
Readers 
familiar 


with the iSBC 86/12 
board 
may want to skip this 
section. 
Next follows a detailed 
description 
of the 


iSBC 
957 package 
and 
the 
iSBC 
86/12 
system 


monitor 
commands. 
A 
program 
example 
of 
a 


matrix multiplication 
routine will then be presented. 


This example 
will contain 
both 
assembly 
language 
and 
PL/M-86 
procedures. 
The 
steps 
required 
to 


compile, 
assemble, 
link, 
locate 
and 
debug 
the 


program 
code will be explained 
in detail. A typical 


debugging 
session 
using 
the 
iSBC 
86/12 
system 


monitor will be presented. 


II. THE iSBC™ 86/12 
SINGLE 
BOARD 


COMPUTER 


The iSBC 86/12 
Single Board Computer, 
which is 


a member 
of Intel's 
complete 
line of iSBC 80/86 
computer 
products, 
is a complete 
computer 
system 
on a single printed-circuit 
assembly. 
The iSBC 86/ 


12 board 
includes 
a l6-bit 
central 
processing 
unit 


(CPU), 
32K bytes of dynamic 
RAM, 
a serial com- 


munications 
interface, 
three programmable 
parallel 


I/O 
ports, programmable 
timers, priority 
interrupt 


control, 
MULTIBUS 
control logic, and bus expan- 


sion drivers 
for interface 
with other 
MUL TIBUS- 


compatible 
expansion 
boards. 
Also included is dual 


port control 
logic to allow the iSBC 86/12 
board 


to act as a slave RAM device to other MUL TIBUS 
masters 
in the system. 
Provision 
is made 
for user 


installation 
of up to 16K bytes of read only mem- 


ory. Figure 1 contains 
a block diagram 
of the iSBC 


86/12 
board 
and 
in Appendix 
A is a simplified 


logic diagram of the iSBC 86/12 
board. 


Central Processing 
Unit 


The central processor 
for the iSBC 86/12 
board 
is 


Intel's 8086, a powerful 
l6-bit H-MOS 
device. The 


225 sq. mil chip contains 
29,000 transistors 
and has 


a clock 
rate 
of 5MHz. 
The 
architecture 
includes 


four (4) l6-bit 
byte addressable 
data registers, 
two 


(2) l6-bit memory base pointer registers and two (2) 
16-bit index registers, 
all accessed by a total of 24 


operand 
addressing 
modes 
for complex 
data 
han- 


dling and very flexible memory addressing. 


Instruction 
Set - 
The 
8086 instruction 
repertoire 


includes 
variable 
length 
instruction 
format 
(in- 
cluding double operand 
instructions), 
8-bit and 
16- 


bit signed 
and 
unsigned 
arithmetic 
operators 
for 


binary, 
BCD and unpacked 
ASCII 
data, 
and iter- 


ative word and byte string manipulation 
functions. 


The 
instruction 
set of 
the 
8086 is a 
functional 
superset 
of 
the 
8080A/8085A 
family 
and 
with 


available 
software 
tools, 
programs 
written 
for the 


8080A/8085A 
can be easily converted 
and run on 


the 8086 processor. 


Architectural 
Features - 
A 6-byte instruction 
queue 


provides pre-fetching 
of sequential 
instructions 
and 


can reduce the 1.21-'sec minimum 
instruction 
cycle 


to 400 nsec by having the instruction 
already in the 


queue. 


The 
stack 
oriented 
architecture 
facilitates 
nested 


sub-routines 
and 
co-routines, 
reentrant 
code 
and 


powerful 
interrupt 
handling. 
The memory 
expan- 


sion 
capabilities 
offer 
a 
1 megabyte 
addressing 


range. 
The dynamic 
relocation 
scheme allows ease 


in segmentation 
of pure 
procedure 
and 
data 
for 


efficient memory utilization. 
Four segment registers 
(code, stack, 
data, 
extra) contain 
program 
loaded 


offset values which are used to map 16-bit addresses 
to 20-bit addresses. 
Each register maps 64K-bytes at 


a time and activation 
of a specific register is con- 


trolled 
explicitly 
by program 
control 
and 
is also 


selected 
implicitly 
by 
specific 
functions 
and 


instructions. 


Bus Structure 


The 
iSBC 
86/12 
board 
has 
an internal 
bus 
for 


communicating 
with 
on-board 
memory 
and 
I/O 


options, 
a system bus (the MUL TIBUS) 
for refer- 


encing 
additional 
memory 
and 
I/O 
options, 
and 


the 
dual-port 
bus 
which 
allows 
access 
to 
RAM 


from the on-board 
CPU and the MUL TIBUS 
Sys- 


tem Bus. Local (on-board) 
accesses do not require 


MUL TIBUS 
communication, 
making 
the 
system 


bus available for use by other MUL TIBUS masters 
(Le. DMA 
devices 
and 
other 
single 
board 
com- 


puters 
transferring 
to additional 
system memory). 


This 
feature 
allows 
true 
parallel 
processing 
in a 


multiprocessor 
environment. 
In addition, 
the MUL- 


TIBUS interface 
can be used fot system expansion 


through 
the use of other 
8- and 
l6-bit iSBC com- 


puters, memory and I/O 
expansion 
boards. 


RAM Capabilities 


The 
iSBC 
86/12 
board 
contains 
32K-bytes 
of 


dynamic 
read/write 
memory. 
Power 
for 
the on- 


board 
RAM 
and refresh 
circuitry 
may be option- 


ally 
provided 
on 
an 
auxiliary 
power 
bus, 
and 


memory 
protect logic is included 
for RAM battery 
backup 
requirements. 
The iSBC 86/12 
board 
con- 


tains a dual port controller 
which allows access to 


the on-board 
RAM 
from 
the iSBC 86/12's 
CPU 


and 
from 
any other 
MUL TIBUS 
master 
via the 


system bus. The dual port controller 
allows 8- and 


16-bit accesses from 
the MUL TIBUS 
System 
Bus 


and the on-board 
CPU transfers 
data to RAM over 


a 16-bit data path. 
Priorities 
have been established 


such that memory 
refresh is guaranteed 
by the on- 
board refresh logic and that the on-board 
CPU has 


priority 
over 
MUL TIBUS 
requests 
for 
access 
to 


RAM. The dual-port 
controller includes independent 


addressing logic for RAM access from the on-board 
CPU 
and 
from the MUL TIBUS 
system bus. The 
on-board 
CPU 
will always 
access 
RAM 
starting 
at 
location 
OOOOOH.Address 
jumpers 
allow 
on- 


board 
RAM to be located 
starting 
on any 8K-byte 


boundary 
within 
a 1 megabyte 
address 
range 
for 


accesses from the MULTIBUS 
system bus. In con- 


junction 
with this feature, 
the iSBC 86/12 
board 


has the ability to protect 
on-board 
memory 
from 


MULTIBUS 
access 
to 
any 
contiguous 
8K-byte 


segments. 
These 
features 
allow 
multi-processor 


systems to establish 
local memory 
for·each 
proces- 


sor and shared system (MUL TIBUS) memory 
con- 


figurations 
where 
the 
total 
system 
memory 
size 


(including 
local 
on-board 
memory) 
can exceed 
1 


megabyte without addressing 
conflicts. 


EPROM/ROM 
Capabilities 


Four 
sockets are provided 
for up to 16K-bytes of 


non-volatile 
read only memory 
on the iSBC 86/12 


board. 
Configuration 
jumpers 
allow 
read 
only 
memory to be installed in 2K, 4K, or 8K increments. 


On-board 
ROM 
is accessed via 16 bit data paths. 
System 
memory 
size is easily 
expanded 
by 
the 


addition of MUL TIBUS compatible memory boards 
available in the iSBC 80/86 
family. 


Parallel 1/ 0 Interface 


The iSBC 86/12 
board 
contains 
24 programmable 


parallel 
I/ 0 
lines 
implemented 
using 
the 
Intel 


8255A 
Programmable 
Peripheral 
Interface. 
The 


system software 
is used to configure 
the I/O 
lines 
in any combination 
of unidirectional 
input / output 


and bidirectional 
ports. 


Therefore, 
the I/O 
interface 
may be customized 
to 


meet specific peripheral 
requirements. 
In order 
to 


take full advantage 
of the large number of possible 


I/O 
configurations, 
sockets are provided 
for inter- 


changeable 
I/O 
line 
drivers 
and 
terminators. 
Hence, the flexibility of the I/O 
interface is further 


enhanced 
by the capability 
of selecting the appro- 


priate 
combination 
of 
optional 
line 
drivers 
and 


terminators 
to provide 
the required 
sink current, 


polarity, 
and drive / termination 
characteristics 
for 


each application. 
The 24 programmable 
I/O 
lines 


and signal ground 
lines are brought 
out to a 50-pin 


edge 
connector 
that 
mates 
with 
flat, 
woven, 
or 


round cable. 


Serial I/O 


A programmable 
communications 
interface 
using 


the 
Intel 
8251A 
Universal 
Synchronous/ 
Asyn- 
chronous 
Receiver /Transmitter 
(USART) 
is con- 


tained 
on 
the 
iSBC 
86/12 
board. 
A 
software 


selectable baud rate generator 
provides the USART 


with all common 
communication 
frequencies. 
The 


USART 
can be programmed 
by the system 
soft- 


ware 
to 
select the 
desired 
asynchronous 
or 
syn- 


chronous 
serial 
data 
transmission 
technique 
(in- 
cluding IBM Bi-Sync). The mode of operation 
(Le., 
synchronous 
or asynchronous), 
data 
format, 
con- 


trol character 
format, 
parity, 
and baud rate are all 


under 
program 
control. 
The 
8251A 
provides 
full 


duplex, double buffered 
transmit 
and receive capa- 


bility. Parity, 
overrun, 
and framing 
error detection 


are all incorporated 
in the USART. 
The RS232C 


compatible 
interface 
on each board, 
in conjunction 
with 
the 
USART, 
provides 
a direct 
interface 
to 


RS232C compatible 
terminals, 
cassettes, 
and asyn- 
chronous 
and synchronous 
modems. 
The 
RS232C 
command 
lines, serial data lines, and signal ground 


line are brought 
out to a 26 pin edge connector 
that 


mates with RS232C compatible 
flat or round cable. 


The 
iSBC 
530 teletypewriter 
adapter 
provides 
an 
optically 
isolated 
interface 
for 
those 
systems 
re- 


quiring 
a 
20 mA 
current 
loop. 
The 
iSBC 
530 


adapter 
may be used to interface 
the iSBC 86/12 


board 
to teletypewriters 
or other 
20 mA 
current 


loop equipment. 


Programmable Timers 


The iSBC 86/12 
board provides three independent, 


fully 
programmable 
16-bit 
interval 
timers / event 


counters 
utilizing the Intel 8253 Programmable 
In- 


terval Timer. 
Each counter 
is capable 
of operating 


in either 
BCD 
or 
binary 
modes. 
Two 
of 
these 


timers / counters 
are 
available 
to the 
systems 
de- 


signer 
to 
generate 
accurate 
time 
intervals 
under 


software control. 
Routing for the outputs 
and gate/ 


trigger 
inputs 
of two of these counters 
is jumper 


selectable. 
The 
outputs 
may 
be 
independently 


routed to the 8259A Programmable 
Interrupt 
Con- 


troller and to the I/O 
line drivers associated 
with 


the 8255A Programmable 
Peripheral 
Interface, 
or 
may be routed 
as inputs 
to the 8255A chip. T e 


gate/trigger 
inputs may be routed 
to I/O 
termin- 
ators associated 
with the 8255A or as output 
con- 
nections 
from the 8255A. The third 
interval 
timer 


in the 8253 provides 
the programmable 
baud 
rate 


generator 
for 
the 
iSBC 
86/12 
RS232C 
USART 


serial port. In utilizing the iSBC 86/12, 
the systems 
designer simply configures, 
via software, 
each timer 


independently 
to meet system requirements. 
When- 


ever a given time delay or count 
is needed, 
soft- 
ware commands 
to the programmable 
timers/ event 


counters select the desired function. 


The contents 
of each counter 
may be read at any 
time 
during 
system 
operation 
with 
simple 
read 


operations 
for 
event 
counting 
applications, 
and 


special commands 
are included so that the contents 
can be ready "on the fly". 


MULTIBUS™ and Multimaster Capabilities 


The MUL TIBUS system bus features asynchronous 
data 
transfers 
for the accommodation 
of devices 
with various 
transfer 
rates while maintaining 
maxi- 
mum throughput. 
Twenty address lines and sixteen 


separate 
data lines eliminate 
the need for address/ 
data 
multiplexing / demultiplexing 
logic 
used 
in 


other systems, and allow for data transfer 
rates up 
to 5 megawords/sec. 
A failsafe timer is included in 
the iSBC 86/12 
board 
which can be used to gener- 


ate an interrupt 
if an addressed 
device does 
not 


respond within 6 msec. 


Multimaster Capabilities - 
The iSBC 86/12 
board 


is a full computer 
on a single board with resources 
capable of supporting 
a great variety of OEM sys- 


tem requirements. 
For those applications 
requiring 


additional 
processing 
capacity 
and the benefits 
of 


multiprocessing 
(Le., 
several 
CPUs 
and/or 
con- 


trollers 
logically 
sharing 
system 
tasks 
through 


communication 
over the system bus), the iSBC 86/ 


12 board 
provides 
full 
MUL TlBUS 
arbitration 


control 
logic. This control 
logic allows up to three 


iSBC 86/12 
boards 
or other bus masters, 
including 


iSBC 80 family MUL TlBUS compatible 
8-bit single 


board 
computers, 
to share the system bus in serial 


(daisy chain) priority 
fashion, 
and up to 16 masters 
to share the MUL TlBUS 
with the addition 
of an 


external priority network. 
The MUL TIBUS arbitra- 


tion logic operates 
synchronously 
with a MULTI- 
BUS clock (provided 
by the iSBC 86/12 
board 
or 


optionally 
provided 
directly 
from the MUL TIBUS 


System Bus) while data is transferred 
via a hand- 


shake between the master 
and slave modules. 
This 


allows different 
speed controllers 
to share resources 


on the same bus, and transfers 
via the bus proceed 


asynchronously. 
Thus, 
transfer 
speed is dependent 


on transmitting 
and 
receiving 
devices 
only. 
This 


design 
prevents 
slow master 
modules 
from 
being 


handicapped 
in their attempts 
to gain control of the 


bus, but does not restrict'the 
speed at which faster 


modules 
can transfer 
data 
via the same bus. 
The 


most 
obvious 
applications 
for 
the 
master-slave 


capabilities 
of the bus are multiprocessor 
configur- 


ations, 
high 
speed 
direct 
memory 
access 
(DMA) 


operations, 
and high speed peripheral 
control, 
but 


are by no means limited to these three. 


Interrupt Capability 


The iSBC 86/12 
board provides 9 vectored interrupt 


levels. The highest level is the NMI (Non-Maskable 
Interrupt) 
line which 
is directly 
tied to the 
8086 


CPU. 
This interrupt 
cannot 
be inhibited 
by soft- 


ware and is typically used for signalling catastrophic 
events (e.g., power failure). 


The 
Intel 
8259A 
Programmable 
Interrupt 
Con- 


troller 
(pIC) 
provides 
vectoring 
for the next eight 


interrupt 
levels. 


The PIC 
accepts 
interrupt 
requests 
from 
the pro- 


grammable 
parallel 
and serial I/O 
interfaces, 
the 


programmable 
timers, 
the system 
bus, 
or directly 


from 
peripheral 
equipment. 
The 
PIC 
then 
deter- 


mines 
which 
of the 
incoming 
requests 
is of 
the 


highest priority, 
determines 
whether 
this request 
is 


of higher 
priority 
than 
the 
level currently 
being 
serviced, and, if appropriate, 
issues an interrupt 
to 


the CPU. Any combination 
of interrupt 
levels may 


be masked, 
via software, 
by storing 
a single byte 


in the interrupt 
mask register of the PIC. The PIC 


generates 
a unique 
memory 
address 
for 
each 
in- 


terrupt 
level. 
These 
addresses 
contain 
unique 


instruction 
pointers 
and code segment offset values 


(for expanded memory operation) 
for each interrupt 


level. 
In 
systems 
requiring 
additional 
interrupt 


levels, slave 8259A PIC's 
may be interfaced 
via the 


MUL TIBUS 
system 
bus, 
to 
generate 
additional 
vector 
addresses, 
yielding 
a 
total 
of 
65 
unique 


interrupt levels. 


Interrupt Request Generation - 
Interrupt 
requests 


may originate 
from 
16 sources. Two jumpe{ select- 


able interrupt 
requests 
can be automatically 
gener- 


ated by the programmable 
peripheral 
interface. 


Two 
jumper 
selectable 
interrupt 
requests 
can 
be 


automatically 
generated 
by the 
USART 
when 
a 


character 
is ready to be transferred 
to the CPU or a 
character 
is ready to be transmitted. 


A jumper 
selectable request 
can also be generated 


by each of the programmable 
timers. 
Eight 
addi- 


tional 
interrupt 
request 
lines are available 
to the 


user for direct interface to user designated 
peripher- 


al devices via the system 
bus, 
and 
two interrupt 


request 
lines may be jumper 
routed 
directly 
from 


peripherals 
via the parallel 
I/O 
driver /terminator 


section. 


Power-Fail 
Control 


Control 
logic is also included to accept a power-fail 


interrupt 
in conjunction 
with 
the 
AC-low 
signal 


from the iSBC 635 Po~er 
Supply or equivalent. 


Expansion 
Capabilities 


Memory 
and I/O 
capacity 
may be expanded 
and 


additional 
functions 
added using Intel MUL TIBUS 


compatible 
expansion 
boards. 
High 
speed integer 


and 
floating 
point 
arithmetic 
capabilities 
may 
be 


added 
by using the iSBC 310 high speed 
mathe- 


matics unit. Memory 
may be expanded 
to I mega- 


byte 
by 
adding 
user 
specified 
combinations 
of 


RAM 
boards, 
EPROM 
boards, 
or 
combination 


boards. 
Input loutput 
capacity may be increased by 


adding 
digital 
110 
and 
analog 
110 expansion 


boards. 
Mass storage 
capability 
may be achieved 


by adding 
single or double 
density 
diskette 
con- 


trollers. 
Modular 
expandable 
backplanes 
and card- 
cages are available to support 
multi board systems. 


III. THE iSBCM 957 PACKAGE 


The iSBC 957 Intellec-iSBC 
86/12 
Interface 
and 


Execution 
Package 
extends 
the software 
develop- 
ment 
capabilities 
of 
the 
Intellec 
Microcomputer 


Development 
systems to the Intel 8086 CPU. 
Pro- 


grams 
for the 8086 may be written 
in PL/M-86 


and 1or 
assembly 
language 
and 
compiled 
or 
as- 


sembled 
on the 
Intellec 
system. 
These 
programs 


may then be downloaded 
from 
an Intellec ISIS-II 


disk file to the iSBC 86/12 
board for execution and 


debug. The programs 
will execute at the full 5 MHz 


clock rate of the 8086 CPU with no speed degrada- 
tion caused by the iSBC 957 hardware 
or software. 


Special communication 
software 
allows transparent 


access to the powerful 
interactive 
debug commands 


in the iSBC 86/12 
monitor 
from the Intellec con- 


sole 
terminal. 
These 
debug 
commands 
include 


single-step 
instruction 
execution, 
execution 
with 


breakpoints, 
memory and register displays, memory 


searches, 
comparison 
of two memory 
blocks 
and 


several other commands. 
After a debugging session, 


the debugged 
program 
code may be uploaded 
from 


the iSBC 86/12 
board 
to an Intellec 
ISIS-II 
disk 


file. 


The iSBC 957 Intellec-iSBC 
86/12 
Interface 
and 


Execution 
Package consists of the following: 


a. Four Intel 2716 EPROMs 
which contain the sys- 


tem monitor program 
for the iSBC 86/12 
board. 


b. An 
ISIS-II 
diskette 
containing 
loader 
software 


for execution 
in the Intellec which provides 
for 


communications 
between the user or an Intellec 


ISIS-II file and the iSBC 86/12 
board. 
Also in- 


cluded on the diskette 
are a library 
of routines 


for system console I/O. 


c. Four cable assemblies used for transmitting 
com- 


mands, 
code and data between 
the iSBC 86/12 


board and the Intellec system. 


d. An iSBC 530 adapter 
assembly 
which converts 


serial communications 
signals from current 
loop 


to RS232C. 


e. Line drivers and terminators 
used for the iSBC 


86/12 
parallel ports. 


f. A small printed 
circuit board 
which is plugged 


into an iSBC 
86/12 
receiver 1terminator 
socket 


and is used when program 
code is downloaded 


or uploaded 
using the parallel cable. 


iSBC™-Intellec 
™ Configurations 


There are two distinct functional 
configurations 
for 


the iSBC 957 package; 
one configuration 
for the 


Intellec Series II, Models 
220 or 230 development 


systems 
and 
another 
for 
the 
Intellec 
800 
series 


development 
systems. 


Intellec Series II System Configurations 


When 
used 
with 
Intellec 
Series II Model 
220 or 


230 systems, a set of cables are used to connect the 
serial I/ 0 port edge connector 
on the iSBC 861 12 


board and the SERIAL 
1 output port on the Intellec 


system. 
This configuration 
is shown 
in Figure 
2. 


How this system functions 
is explained 
in the fol- 


lowing paragraphs. 


The SERIAL 
1 port on the Intellec Series II Model 


220 or 230 system is an RS232 port 
which is de- 


signed for use with a data terminal. 
This port may 


be used on the Intellec 
system 
for interfacing 
to 


RS232 devices such as CRT terminals 
or printers. 


The serial ports on the iSBC 86/12 
board 
and the 


Intellec 
systems 
are 
connected 
as 
shown 
in the 


Figure 
2. The flat ribbon 
cable connected 
to the 


iSBC 86/12 
board 
has an edge connector 
for con- 


necting 
to the board 
on one end and 
a standard 


RS232 
connector 
on the 
other 
end. 
The 
second 


cable, 
the RS232 
Up/Down 
Load 
cable, 
has an 


RS232 connector 
on each end. This cable, however, 


is not a standard 
cable with the RS232 signals bussed 
between 
identically 
numbered 
pins on each of the 


connectors. 
The schematic for the cable is shown in 
Figure 
3. Note that 
the TXD 
(transmit 
data) 
and 
the RXD (receive data) and the RTS (ready to send) 
and 
the 
CTS 
(clear 
to 
send) 
signals 
have 
been 


crossed. This is done because both the Intellec system 
and the iSBC 86/12 
board are configured 
to act as 
data 
sets 
which 
are 
communicating 
with 
data 
terminals. 
Swapping 
these signals permits the units 
to communicate 
directly 
with no modifications 
to 
the Intellec or iSBC 86/12 
systems themselves. 


FGD 
1 


TXD 
2 


RXQ 
3 


RTS 
4 


, 
FGD 
(FRAME GROUND) 


2 
TXD 
(TRANSMIT 
DATAl 


3 
RXD 
(RECEIVE DATAl 


4 
RTS 
(READY TO SENDI 


5 
CTS 
(CLEAR TO SENDI 


7 
SGO 
(SIGNAL 
GROUND) 


Figure 3. IntellecTM-iSBCTM 
86/12 
RS232 
UP / DOWN LOAD Cable 


The software in the Inte\lec system accepts characters 
output 
from 
the iSBC 
86/12 
board 
through 
the 
Intellec SERIAL 
1 port. The software 
then outputs 


these characters 
on the CRT monitor 
built into the 
Intellec 
Series II Model 
220 or 230. In a similar 
fashion, 
characters 
input 
from 
the 
Intellec 
key- 


board 
are passed down the serial link to the iSBC 


86/12 
monitor 
program. 
The 
integrated 
CRT 


monitor 
and keyboard 
on the Intellec system then 


becomes the "virtual 
terminal" 
of the iSBC 86/12 


monitor 
program. 
If this were the only function 
of 


the 
iSBC 
957 package, 
there 
would 
be no 
real 


benefit 
to the user. 
However, 
when 
the 
"virtual 


terminal" 
capability 
is combined 
with 
the 
capa- 


bility to download 
and upload 
program 
code and 


data 
files between 
the Intellec 
ISIS-II 
file system 


and the iSBC 86/12 
board, 
a very powerful 
soft- 


ware development 
tool is realized. 
The software 
in 


the 
Intellec 
system 
must 
examine 
the commands 


which are input from the keyboard 
and in the case 


of 
the 
LOAD 
and 
TRANSFER 
commands 
(see 


later 
sections 
for details 
on monitor 
commands), 


the software 
must open and read or write ISIS-II 


disk files. 


Transfer 
rates using Intellec Series 11 Model 220 or 


230 system are 9600 baud when transferring 
hexa- 


decimal object files to or from a disk file and 600 
baud 
when 
transferring 
commands 
between 
the 


iSBC 86/12 
board 
and the CRT monitor 
and key- 
board. 
With a 9600 baud transfer 
rate, 
it is pos- 


sible to load 64K bytes of memory 
in about 
four 


minutes. 


Intellec 800 System Configurations 


The iSBC 957 package 
may be used with the In- 
tellec 800 system in four different 
configurations. 


These 
four 
configurations 
are d.etermined 
by two 


variables. 
The 
first variable 
is whether 
the iSBC 


86/12 
board 
is conl1ected to the Intellec 800 TTY 


port or to the Intellec 800 CRT port. 
The second 


variable 
is whether 
or not a parallel 
cable is used 


for uploading 
and downloading 
hexadecimal 
object 


files. 
Figures 
4A 
and 
4B 
illustrate 
the 
four 


configurations. 


In Figure 
4A, 
the configuration 
shows 
the TTY 


port 
of the 
Intellec 
800 system 
connected 
to the 


iSBC 
86/12 
serial 
port 
using 
two cables 
and 
an 


iSBC 530 teletypewriter 
adapter. 
The TTY port of 


the 
Intellec 
800 system 
is designed 
for 
using 
a 


teletypewriter 
'as the Intellec console device. To use 


this port for communication 
with the iSBC 86/12 


board, 
the current 
loop TTY signal must be con- 


verted to an RS232 compatible 
voltage signal. This 


function 
is performed 
by the iSBC 
530 adapter. 


The cable which connects the Intellec 800 system to 
the iSBC 530 adapter 
performs 
a function 
similar 


to 
the 
RS232 
Up/Down 
Load 
cable 
described 


above. 
A schematic 
for 
this 
cable 
and 
all other 


components 
of the iSBC 957 package 
are included 


with the delivered product. 


The 
transfer 
rate 
for 
both 
commands 
and 
data 


when the TTY port is connected 
to the iSBC 86/12 


board 
is 110 baud. 
This means 
to download 
even 


moderately 
sized 
programs 
would 
require 
large 


amounts 
of time, 
several minutes 
or even hours. 


However, 
much 
faster 
times 
may be achieved 
by 


using the parallel 
ports 
of the iSBC 86/12 
board 


imd the Intellec system 
for downloading 
program 


files. This 
parallel 
port 
used 
on the 
Intellec 
800 


system is the output 
port labeled 
PROM 
which is 


normally 
used 
with 
the 
Universal 
Prom 
Pro- 


PARALLEl 
LOAD 
CABLE 


(OPTIONAU 
I 


Q~ 


~, 
'iSBC530 
TTY ADAPTER 
TTY 
UP I DOWNLOAD 


CABLE 


TOTTY 


-TERMINA~~ 


OEM AS232-C 
CABLE 


grammer. 
A cable 
is connected 
between 
the 
In- 


tellec PROM 
port and the parallel I/O 
port, 
11 of 


the iSBC 86/12 
board. 
Parallel port B of the iSBC 


86/12 
board 
is used 
for the 
8-bit byte transfers 
from the Intellec system to the iSBC 86/12 
board, 


port A is used for the byte transfers 
from the iSBC 


86/12 
board 
to the Intellec system and port 
C is 
used for controlling 
the byte transfers. 
A special 


status 
adapter 
piggyback 
board 
must 
be inserted 


into a receiver /terminator 
socket of the iSBC 86/12 


board. 
This 
status 
adapter 
circuit 
is required 
to 


provide the necessary handshaking 
signals from the 
iSBC 86/12 
parallel 
ports 
to the Intellec 
PROM 


port. 
The transfer 
rate achieved 
when downloading 
and 


uploading 
hexadecimal 
object files with the parallel 


cable is approximately 
1,000 bytes per second. The 


time 
required 
to 
load 
64K bytes 
of 
memory 
is 


approximately 
2Y2 minutes. 


Figure 4B shows a configuration 
with the Intellec 
800 CRT port 
connected 
to the serial port of the 
iSBC 86/12 
board. 
The TrY port of the Intellec 
800 system is connected 
to a teletypewriter 
or some 
other 
current 
loop device to act as a system con- 


sole. The optional 
parallel load cable is also shown. 
The cables used for this configuration 
are the same 
as those used with the Intellec Series II Configur- 
ations. 
Command 
transfer 
rates require 
110 baud 


because the TrY port of the Intellec 800 system is 
used 
for communicating 
with the console 
device. 
However, 
hexadecimal 
object files can be loaded at 
9600 baud since this operation 
uses only the Intellec 
to iSBC 86/12 
RS232 link. 


It is also possible to download 
files with the parallel 


cable, 
this mode 
being somewhat 
faster 
than 
the 


serial 
download 
mode 
(2 Y2 
minutes 
versus 
four 


minutes 
for 64K bytes of memory). 
Table 
I con- 
tains 
a summary 
of the 
command 
and 
memory 
transfer 
rates for each of the Intellec-iSBC 
86/12 


configurations. 


Comparing 
the Intellec 800 configurations 
shown in 


Table 
I and 
in Figures 
4A and 
4B it should 
be 


noted: 


I. Using the TrY port 
(Figure 4A) of the Intellec 
800 system 
for communications 
with the iSBC 
86/12 
board 
(essentially) requires installation 
of 
the parallel 
cable and jumper 
modifications 
for 


downloading 
and uploading 
files, and thus, pre- 


vents the use of the parallel ports for other I/O 
functions. 


2. Using the €RT 
port 
(Figure 4B) of the Intellec 


800 system 
for 
communication 
with 
the iSBC 


86/12 
board 
provides 
for a fast serial download 


capability, 
thus 
freeing 
the 
parallel 
ports 
for 


other uses. However, 
this configuration 
requires 


a teletypewriter 
or a CRT capable 
of accepting 


a current loop input signal as the Intellec system 
console. 


Table 1 


COMMAND 
AND 
MEMORY 
TRANSFER 
RATES 
FOR 


INTELLEC-iSBCTM 
86/12 
CONFIGURATIONS 


INTElLEC 


SERIES 
II 220/230 
SERIAL 
PORT 
TO 
iSBC 
86/12 


INTELLEC 
800 
TTY 
PORT 


TO 
;SBC 
86/12 


INTELLEC 
BOO 
CRT 
PORT 


TO 
;SBC 
86/12 


Effective 
Command 
Rate 
600 Baud 
110 Baud 
110 Baud- 


load I Transfer 
Rate 
Serial 
9600 
Baud 
110 Baud 
9600 
Baud 


Parallel 
N/A 
lK bytes/sec·' 
lK bytes/sec·· 


Approximate 
Time 
to load 
64K 
bytes 
of memory 
Serial 
4 minutes 
5 hours 
4 mInutes 


Parallel 
N/A 
2.5 minutes 
2.5 minutes 


"The actual baud rate of the Intetlec-iSBC 
86·· 12 link 
is 9600 baud 
but the effective 


command 
rate is determined 
by the slower 
Intellec - 
console 5enallink 


··TransrruSSlQn rate over the parallellmk 
ISdetermined 
by the speed of the two processors 


and IS apprOllimatelv 
lK bytes per second. 


IV. THE iSBC 957-iSBC 
86/12 
MONITOR 


PROGRAM 


The iSBC 86/12 
monitor 
program 
is an EPROM 


resident 
program 
which 
facilitates 
debugging 
of 


user written programs. 
The monitor 
program 
used 


in the iSBC 86/12 
board 
with the iSBC 957 pack- 


age is the same monitor 
program 
written 
to inter- 


face the iSBC 86/12 
directly 
to an 
RS232C 
data 


terminal. 
When 
interfaced 
directly 
to a terminal, 


the iSBC 86/12 
board 
functions 
in a stand-alone 


environment 
communicating 
directly 
with the user 
via the data terminal. 
A user may use the monitor 


for entering small programs 
in hexadecimal 
format, 


executing 
a 
program, 
examining 
registers 
and 


memory contents, 
etc. 


To use the monitor 
program 
with an Intellec system, 


the proper 
cables must be installed 
and the iSBC 


957 Loader 
program 
must be loaded 
into Intellec 


memory and execu ed. The Loader program 
is resi- 


dent on a file named 
SBC861, and when executed, 


the Loader 
outputs 
a sign-on 
message. 
Next, 
the 


iSBC 86/12 
monitor 
program 
must be started 
and 


the baud rate of the iSBC 86/12 
to Intellec serial 


communications 
link must 
be determined. 
This is 


done by pressing the RESET 
switch on the chassis 


Table 2 


MONITOR 
COMMAND 
LIST 


COMMAND 
FUNCTION 
AND 
SYNTAX 


Load Hex 
Loads hexadecimalobject file from Intellec into iSBC 


Object File 
86/12 
memory using serial (5) or parallel (PI mode. 


L{51p} ,< filename>(, <bias addr>]<cp 


T Transfer Hex 
Transfers blocks of iSBC 86/12 memory to Intellec as 
Object File 
a hex object file using serial (Sl or parallel(PI mode. 
nXl {SIP} 
,<.Start addt>,<end addp, 
< filename> 


l,<exec 
addr>]<cp 


Executes one user program instruction. 


N[<add,> L[[<add,>], f* <: cr> 


Transfers control of the 8086 CPU to the user program 
with up to 2 optional breakpoints. 


Gf<start addpl 
(,<break 1 addr> 


L<break 2 addr>] }<Cf,. 


Displays/modifies memory locations in byte or word 
format. 


S(WJ<addr>, 
[ [new 
contents!.)" 
<cr> 


X Examine/Modify 
Displays/modifies ~ 
CPU registers. 


Register 
Xf<reg>l 
[I<new 
contents>Ll"<cf> 


D Display Memory 
Displays contents of a memory block in byte or word 
format. 


DfWl<start 
addr>[,<end 
addr>}<cr> 


M.ovescontents of a memory block. 


M<start 
addr>,<end 
addf>,<destination 
addr><cf> 


Compares two memory blocks. 


C<start 
addr>,<end 
addr>,<destination 
addr><cf> 


Searches a memory block for a byte or word constant. 


F[W]<start 
addr>,< 
end addr>.<data><cr> 


Performs hexadecimal addition and subtraction. 


H<data 
1>,< data 
2><cr> 


Inputs and displays byte or word data from input 
port. 


I[W]<port 
addr>,U"<cr> 


Outputs byte or word data to output port. 


O[W]<port 
addr>,<data>I,<data>j4<cr> 


Syntax conventions used in the command structure are as follows: 


fA} 
indicates that" A" is optional 


[Al" 
indicates one or more optional iterations of "A" 


<B> 
indicates that "B" is a variable 


{Ala} indicates "A" 
or "8" 


<cr> 
indicates a carriage return is entered 


Numeric arguments can be expressed as a number, the contents of a register, 
or the sum or difference of numbers and register contents. Thus, addresses 
and data can be expressed as follows: 


addr 
!<expr>.'1<expr> 


expr 
<number>l<register>!<expr> 
{+ I-} 
<number>1 


<expr> 
{+ I-} 
<register> 


,eg;5I" ::~ 
AXIBXICXIDXISPIBPlsllDqcslDSISSIESllPIFL 


number 
:: = 
<digit>l<digit><number> 


Numeric fields within 
arguments are entered as hexadecimal numbers. The 
valid range of numerical values is from ()(X,X).FFFF. 
Larger numbers may be 
entered, but only the last four digits (or two in the case of byte values) are 
significant. Leading zeros may be omitted. 


An address argument consists of a segment value and an offset value separ- 
ated by a colon (:). If a segment value is not specified, the default segment 
value is the CS register value. 


containing 
the iSBC 86/ 12 board 
and typing 
two 
"U"s 
on the lntellec console. The ASCII uppercase 


character 
U has a binary pattern of alternating 
ones 


and zeros, the iSBC 86/12 
monitor 
uses this pattern 


to determine 
the baud rate of the serial link. After 


the baud 
rate 
has been 
determined, 
the monitor 


program 
outputs 
a sign-on message to the console. 


An 
example 
of 
loader 
program 
execution 
and 


monitor 
program 
initialization 
is shown below (user 


entered characters 
are underlined). 


:Fl:SBC861 
ISIS-II iSBC 86/12 
LOADER, 
Vx.x 


(user resets iSBC 86/12 
board and types two "U"s) 


~SBC 86/12 
MONITOR, 
Vy.y 


The monitor 
prompts 
with a period 
"." 
when it is 


ready 
for a command. 
The user can then enter a 


command 
fil~, which 
consists 
of a one- 
or two- 


character 
command 
followed by zero, one, or more 


arguments. 
The command 
may be separated 
from 


the first argument 
by an optional 
single space; 
a 


single comma 
is required 
as a delimiter 
between 


arguments. 
The command 
line is terminated 
by a 


carriage return or a comma depending 
on the com- 
mand, and no action takes place until the command 
terminator 
is sensed. 
The user can cancel a com- 


mand 
before 
entering 
the command 
terminator 
by 


pressing any illegal key (e.g., rubout or Control-X). 


Table 
2 contains 
a summary 
of the 
loader 
and 
monitor 
commands. 
These commands 
will not be 
explained 
in detail; instead, 
the next section of the 


application 
note will show examples 
of using these 
loader 
and 
monitor 
commands. 
The 
iSBC 
957 


User's 
Guide referenced 
at the front 
of this docu- 
ment does, however, 
contain a complete description 


of each of the monitor 
and loader commands. 


Table 3 contains a list of the 8086 hardware 
registers 


and abbreviations 
used by the monitor 
program. 


Table 3 


8086 CPU REGISTERS 


REGISTER 
NAME 
ABBREVIATION 


Accumulator 
AX 


Base 
BX 


Count 
CX 


Data 
OX 


Stack Pointer 
SP 


Base Pointer 
BP 


Source 
Index 
SI 
Destination 
Index 
01 
Code Segment 
CS 


Data Segment 
OS 


Stack Segment 
SS 


Extra Segment 
ES 


Instruction 
Pointer 
IP 
Flag 
FL 


ON-BOARD 
{ 
FFFFFH 
39 
EPROM 
MONITOR 
PROGRAM 


18K 
bytes) 
FECOOH 
38 


37 


36 


35 


34 


33 


AVAILABLE 
32 
8000H 
------ 
USER 
------ 


AREA 
31 


ON-BOARD 
RAM 


132K 
bYtes} 


INTR 7 


INTR 6 
-- 
INTR 5 


INTR 4 


INTR 3 


INTR 2 


INTR 1 


lNTR 0 


9CH 


98H 


94H 


90H 
8259A PIC 


BCH 
VECTORS 


88H 


84H 


60H 


RESERVED 


FOR 


FUTURE 
USE BY 
INTEL 


Figure 
5 contains 
a memory 
map 
of the iSBC 


86/12 
memory 
with the monitor 
program. 
Note 


that the monitor uses the top 8K bytes of memory 
for its program 
code and the first 384 bytes of 
memory (locations ~ hex to 17F hex) for monitor 
and user stack, data and interrupt 
vectors. When 


the monitor program is reset, the segment registers, 
the IP and the flags are set to 0; and the SP is set 
to 01C~H allowing 64 bytes for the user's stack. If 
64 bytes is not sufficient for the user's application 
program, the SP should be set to some other value. 
The monitor program 
sets the single-step, one-byte 


instruction trap and non-maskable 
interrupt vectors 
to monitor entry points. The monitor also sets the 
8259A Priority Interrupt 
Controller to fully nested 


mode with level 0 'at the highest priority 
and all 


interrupts 
unmasked. 
The 
eight interrupt 
vector 


addresses for the 8259A are also set to addresses in 
the monitor. User programs may change the 8259A 
interrupt 
vectors to interrupt 
service routine 
ad- 


dresses within the user programs; it is not necessary 
for users to program the 8259A chip directly. When 
an interrupt 
occurs, 
control 
passes to either the 


monitor or directly to user code depending on the 
address 
stored 
in the vector location. 
When 
the 
monitor 
responds to an interrupt, 
it acknowledges 
the interrupt 
and displays the interrupt 
level, CS 


and IP register values and next instruction byte on 


the system console (e.g., 1=3 
@ lOO:230FF5). 


When a user requests a breakpoint 
with a "0" 


command, 
the 
monitor 
inserts 
the 
single 
byte 


instruction trap instructions (INT 3) in the location 
where the breakpoint is requested. It is also possible 
for the user to code an INT 3 instruction 
in his 


program. 
When a user coded INT 3 instruction 
is 


executed, the monitor will be re-entered and a line 
with the format 
@<CS Value>:<IP 
Value> <In- 


struction byte> will be displayed (e.g., @ 1200:3F02 
F5). 


Included on the diskette with the Loader program 
are two libraries containing 
I/O 
routines 
for the 


console. The library files are named SBCIOS.LIB 
and 
SBCIOL.LIB; 
they contain 
similar routines. 


The 
routines 
in SBCIOS.LIB 
are written 
to 
be 


called with intrasegment subroutine calls, a PL/M- 
86 module 
compiled 
with 
the 
"small" 
control 


generates 
this 
type 
of 
call. 
The 
routines 
in 


SBCIOL.LIB 
are written to be called with interseg- 


ment subroutine 
calls, a PL/M-86 
module 
com- 


piled with either the "medium" 
or "large" 
control 


generates this type of call. 


The console input 
output 
routines, 
CI and 
CO, 


contained in the library should be used when per- 
forming character input and output on the console. 
Example PL/M-86 
calls to the two routines are: 


CI: 
PROCEDURE 
BYTE EXTERNAL; 


ENDCI; 


CO: PROCEDURE 
(X) EXTERNAL; 


DECLARE 
X BYTE; 
END CO; 


DECLARE 
INPUT$CHAR, 
OUTPUT$CHAR 
BYTE; 


General Comments 
on Use of the iSBC 957 Package 


1. If the iSBC 86/ 12 board 
is reset any time after 


the initial baud rate search, it is not necessary to 
reload 
the 
iSBC 
957 
Loader 
program 
or 
to 


download 
the program 
code a second time to the 


iSBC 86/12 
board. 
It is only necessary 
to re- 
establish the communications 
link by typing two 


"U"s 
for the baud rate search. 


2. The iSBC 86/12 
board 
should 
not be plugged 


into an available 
card slot in an Intellec chassis; 


a separate 
chassis should 
be used. There are at 


least three reasons for this: 


a. There is only one RESET 
signal available 
on 


the Intellec system bus. Thus, 
each processor 


may not be reset independently. 
This means 
that 
the iSBC 
86/12 
,?oard cannot 
be reset 


without 
re-booting 
the ISIS-II 
operating 
sys- 


tem and restarting 
the iSBC 957 Loader. 


b. The Intellec system uses five of the eight avail- 


able interrupts 
on the system bus. This severely 


restricts 
the range 
of interrupts 
available 
to 


the iSBC 86/12 
board. 
Also, the iSBC 86/12 


board 
cannot 
turn-off 
the interrupt 
lamps on 


the Intellec front panel. 


c. The iSBC 86/12 
board 
may address 
up to I 


Megabyte 
of memory 
using a 20 bit address. 
Many 
Intellec 
systems 
contain 
boards 
which 


generate 'and 
decode 
only 
the low order 
16 


address bits. For example, 
the iSBC 016 mem- 


ory 
expansion 
board 
and 
the 
Intelle.c 
800 


monitor 
PROMs 
only decode 
16 address 
bits. 


Memory 
expansion 
above 64K bytes in these 
systems is difficult 
since the boards 
which de- 


code 
only 
16 bits will force 
"holes" 
in the 


address space above 64K. 


3. The 
iSBC 
86/12 
board 
is delivered 
with 
two 


inputs to the 8259A Priority 
Interrupt 
Controller 


connected. 
Interrupt 
request 2 (IR2) is connected 


to the counter 
~ output 
of. the 8253 Program- 


mable 
Interval 
Timer. 
IR5 is connected 
to the 


INT5/signal 
of the MULTIBUS 
System Bus. If 


these interrupts 
are not desired, 
the wire wrap 


jumpers 
making 
the connections 
should 
be re- 


moved from the iSBC 86/12 
board. 
A particular 


problem 
may exist with the counter ~ connection 


to IR2. If the 8253 counter 
~ is not specifically 


initialized with software, 
a low frequency 
square 


wave output 
will exist at counter ~'s output. 
This 


may cause unwanted 
interrupts 
when interrupts 


are enabled by user programs. 


4. If the iSBC 86/12 
board is used in a system with 


expansion 
boards, 
it is important 
that the MUL- 


TIBUS bus exchange pins be properly jumpered. 
For example, 
if the iSBC· 86/12 
board 
is used 


with an iSBC 032 expansion 
memory 
board in a 


system, 
the 
BPRN / 
MUL TIBUS 
pin 
for 
the 


iSBC 86/12 
board should be grounded. 


In addition, 
if any interrupts 
are used with the 


iSBC 
86/12 
board 
the 
BPRN / 
pin must 
be 
grounded. 
This is true in both 
single and mul- 
tiple board systems. 


5. Certain user systems require more than one single 


board computer 
in the system for performing 
the 


functions 
required by the application. 
The MUL- 


TIBUS System Bus has been specifically designed 
to permit multiple 
CPU boards 
to communicate 


and 
to 
share 
system 
resources. 
However, 
de- 


bugging systems with multiple 
CPUs has always 


posed 
somewhat 
of a problem. 
The iSBC 957 


package provides a solution to this problem. 
The 
serial 
cable 
which 
connects 
the 
iSBC 
86/12 


board 
to the 
Intellec 
system 
may 
be removed 


after 
the program 
has been downloaded 
to the 


iSBC 86/12 
board. 
A console CRT may then be 


connected 
directly to the iSBC 86/12 
board 
and 


the monitor 
program 
may be used to debug the 


program 
running 
on 
the 
board. 
Other 
iSBC 


86/12 
boards may also be downloaded 
from the 


Intellec system and then switched 
to their 
own 


local terminals. 
An 8-bit processor 
board, 
such 


as the iSBC 80130 board, 
may also be included 


in the system 
and 
ICE-85™ 
may 
be used 
for 
debugging the iSBC 80/30 
program 
concurrently 


with 
the 
iSBC 
86/12 
programs. 
Using 
this 
scheme, 
it is possible 
to debug a system which 
has several CPU 
boards 
by setting breakpoints 
and using other 
debugging 
features 
on each of 


the individual 
CPUs. 


V. MATRIX 
MULTIPLICATION 
EXAMPLE 


To illustrate how the iSBC 957 package can be used 
to assist in the writing and debugging of 8086 pro- 
grams on the iSBC 86/12 board, 
an example 
pro- 


gram of a matrix 
multiplication 
will be presented. 
The 
example 
chosen 
has 
been 
intentionally 
kept 


simple and 
straightforward. 
The emphasis 
of this 


section will be to document 
the steps required to as- 


semble, 
compile, 
link, 
locate 
and 
debug 
software 
using an Intellec system, the iSBC 957 package and 
the iSBC 86/12 board. 
Part of the example will be 


written in 8086 assembly language and part in PL/ 
M-86. 


The 
main 
program 
is written 
in PL/M-86. 
The 
main 
program 
first 
performs 
some 
initialization 


and 
the 
matrix 
multiplication, 
then 
the 
program 


calls an assembly 
language 
procedure 
(subroutine), 


a PL/M-86 
procedure 
and the console output 
pro- 


cedure CO supplied in the I/O 
library on the iSBC 


957 
diskette. 
A 
flow 
diagram 
for 
the 
example 


program 
is shown in Figure 6. 


Explanation 
of the Program 
Code 


The program 
code is contained 
in three 
software 
modules 
EXECUTION$VEHICLE, 
FIND, 
and 


SBCCO. 
EXECUTION$VEHICLE 
contains 
the 


main program 
coded in PL/M-86 
and the binary 


to 
ASCII 
conversion 
procedure 
BIN$DEC$ASC 


also coded 
in PL/M-86. 
The module 
FIND 
con- 


tains the assembly 
language 
procedure 
FIND$MX 


which 
searches 
a matrix 
for its maximum 
value. 


The module 
SBCCO 
resides in the library 
of con- 


sole I/O 
routines supplied with the iSBC 957 pack- 


age. 
The 
procedure 
CO 
will be used 
from 
this 
library. 


The program code for the EXECUTION$VEHICLE 
and FIND modules 
will be explained 
in the follow- 


ing paragraphs. 
Appendix 
B contains 
compilation 


and 
assembly 
listings 
for 
the two 
modules; 
also 


contained 
in Appendix 
B is a memory 
and debug 
map 
for the linked 
modules. 
The listings contain 


circled reference letters (e.g., @) which are referred 
to by the code description 
below. The listings in the 


appendix 
have been printed 
on fold-out 
pages 
so 
that they may easily be seen when reading the text. 


MultIply 
Matrices, 


store result in 


ZSAQW 


Output 
MAX 


value 
on 
terminal 
uSing 
CO routine 


Figure 6. 


Flow Diagram of Matrix 
Multiplication 
Example 


Much of the description 
given below assumes 
that 


the reader 
is familiar 
with the PL/M-86 
language 


and compiler, 
the 8086 assembler, 
and the link and 


locate program 
QRL86. 
It is recommended 
that the 


reader 
have at least a cursory 
knowledge 
of these 


subjects. 
The Intel literature 
for these subjects 
is 


listed near the front of this application 
note. 


The EXECUTIONSVEHICLE 
Module 
® The first section of the module 
includes 
intro- 


ductory 
comments 
and then statements 
to de- 


clare 
the 
matrices, 
other 
variables, 
and 
pro- 


cedures 
used 
in the 
program. 
Note 
that 
the 


matrix dimensions 
are declared using the literals 


M, N, and P which are initially set to 6, 5, and 
3. Later 
in this note, 
other 
values 
for M 
N 


and P will be used. 
' 
, 


® The 
next 
section 
of 
code 
contains 
the 
state- 


ments which initialize the two matrices that will 
be multiplied 
X$ROW and Y$ROW. 


As a result of this initialization, 
the two ma- 


trices will contain values as shown in Figure 7. 


0 
0 
0 


[j 


-, 
'] 


-1 
-2 


2 
-, 
-2 


-1 
-2 


-, 
-2 


Figure 7. 
X$ROW and Y$ROW Matrices 
After 
Initialization 


© The next program 
section performs 
the matrix 
multiplication. 
The algorithm 
required 
to mul- 
tiply two matrices X and Y, storing the result in 
a third matrix Z is: 


n 


Zmp 
= L 
Xmi *Yip 
i = I 


Assuming 
X to be 6X5 matrix 
and 
Y a 5X3 


matrix then 


ZII =X11Y11+X1'Y'1 +XllY11 +XI4X.1 +X1SYS1 


Thus, the upper left term is equal to the sum of 
the products 
of the top row of the X matrix 
times the left column 
of the Y matrix. 
The re- 
sult that 
is obtained 
by multiplying 
the 
two 


matrices 
X$ROW 
and Y$ROW 
after 
they are 
initialized 
as 
explained 
above, 
is 
shown 
in 


Figure 8. 


Figure 8. Result of Multiplying 
the Initialized 
Matrices 


X$ROW and Y$ROW 


® The 
external 
assembly 
language 
procedure 


FIND$MX 
is called to determine 
the maximum 


value in the matrix. 
Th.e procedure 
is a typed 


procedure 
and 
returns 
the maximum 
value to 


the calling program 
which stores it in the inte- 


ger variable MAX. 


® The maximum 
value is then converted 
to a six 


(6) digit 
ASCII 
character 
string 
by the 
pro- 


cedure BIN$DEC$ASC. 
The character 
string is 


stored in the array MAX$ASC$ARRA 
Y, which 


contains 
the sign of the number 
and 
five (5) 


digits for th~ magnitude. 
® Finally, the characters 
"MAX 
VALUE 
are 


output 
on the system console 
followed 
by the 


6 ASCII 
characters 
containing 
the maximum 
value. 
The PL/M-86 
built-in 
procedure 
SIZE 


returns the number 
of bytes of the array TEXT 


as a word 
value. 
The 
PL/M-86 
built-in 
pro- 


cedure SIGNED 
changes the type of the value 
from WORD to INTEGER. 
This is required 
so 


that the type of the arguments 
in the DO state- 


ment agree. The console output 
procedure 
CO 


is used to output 
the characters 
on the system 


console. 
@ Also contained 
in the module 
MATRIX.PLM 


is the binary 
to ASCII 
conversion 
procedure 


BIN$DEC$ASC. 
The first portion 
of the code 


contains 
the 
comments 
explaining 
the 
para- 


meters and the calling sequence followed by the 
declarations. 
Note that the address of the array 


where the characters 
are to be stored is passed 


to the procedure 
and that the characters 
will be 
stored in the array 
using based variables. 
The 


next section of the code stores either a + or - 
sign in the first character 
position of the ASCII 


array and stores the absolute 
value of VALUE 


in the variable TEMP. 
Finally, the binary value 


is converted 
to 
ASCII 
using 
the 
algorithm 


explained in the comments. 
The MOD operator 


returns the remainder 
of the division by 10. The 


UNSIGN 
built-in 
procedure 
is 
required 
to 


change the type of the expression 
from 
INTE- 


GER to WORD. 


The FIND Module 
® The FIND 
module 
contains 
the assembly 
lan- 


guage 
procedure 
FINDMX. 
The 
calling 
se- 


quence and the parameters 
are explained 
in the 


comments 
at the beginning 
of the listing. Note 


that 
the 
label 
FINDMX 
has 
been 
declared 


PUBLIC 
so the 
link 
program 
can 
fill in its 


address 
in the 
CALL 
statement 
in the 
main 


program 
of module EXECUTION$VEHICLE. 


CD 
The FIND module 
will contain 
three segments: 


a data 
segment, 
a stack 
segment 
and 
a code 
segment. 
It will be both 
convenient 
and prag- 


matic 
to append 
these 
three 
segments 
to the 


code, 
data 
and 
stack segments 
created 
by the 


compiler 
for 
the 
EXECUTION$VEHICLE 
module. 
To accomplish 
this, the three segments 
must be given the same SEGMENT 
and CLASS 
names 
as those 
given 
these 
segments 
by the 


compiler. 
The SEGMENT 
and CLASS 
names 
used by the compiler 
are CODE, 
DATA, 
and 


STACK. 
The GROUP 
statements 
are used to 


place the segments 
DATA 
and STACK 
in the 


group DGROUP 
and the segment CODE in the 
group CGROUP. 
These group definitions 
con- 


form 
with the group 
definitions 
generated 
by 


the PL/M-86 
compiler 
when the SMALL 
size 


control 
option 
is used. A group 
is a collection 
of segments which requires less than 64K bytes 
of memory. 


The ASSUME 
directive informs 
the assembler 


that 
the DS and 
SS registers 
will contain 
the 
base address 
of DGROUP 
and the CS register 


will contain 
the 
base 
address 
of 
CGROUP. 


This information 
will be used by the assembler 


when constructing 
machine instructions. 


The first segment 
appearing 
in the module 
is 


the data segment. 
The order of the segments is 


arbitrary, 
although 
it is recommended 
that the 


data segment precede the code segment to mini- 
mize forward 
references to variables which may 


cause the assembler 
to generate 
longer instruc- 
tion 
codes. 
The 
data 
segment 
is 
declared 


PUBLIC, 
aligned 
on a WORD 
boundary 
and 


given both a segment and class name of DATA. 
Then 
follows 
the contents 
of the segment. 
In 


this panicular 
example, 
only one word of stor- 


age is required. 
The ENDS 
directive 
indicates 


the end of the segment. 


Next comes 
the stack 
segment 
which is given 


the 
segment 
name 
of 
STACK, 
the combine- 


type attribute 
of STACK and the class name of 


STACK. The combine-type 
attribute 
of STACK 


assures 
that 
the stack 
storage 
required 
in this 
module 
will be. appended 
to 
the 
storage 
re- 
quired in the PL/M-86 
compiled modules. 
Two 


bytes of stack are required 
by the code in this 
module, 
however, 
the monitor 
uses 13 words of 


stack when breakpoints 
and interrupts 
are used. 
Therefore, 
14 words are reserved for the stack. 


Finally comes the code segment. 
The code seg- 


ment has been given a segment name and class 
name 
of 
CODE 
and 
a 
group 
name 
of 


CGROUP, 
and 
has 
been 
declared 
PUBLIC. 


The alignment 
attribute 
of BYTE 
is specified 


since 
it 
is 
desired 
that 
the 
code 
from 
this 


module 
be appended 
directly to the code from 


other 
modules 
without 
gaps between 
the code 


modules. 


The assembly 
language 
code follows next. The 


code 
for the procedure 
must 
be enclosed 
be- 


tween a pair of PROC, 
ENDP 
statements. 
The 


PROC 
statement 
is given the label FINDMX 


and specified as a NEAR 
procedure 
indicating 


it will be called 
with 
a near 
(intra-segment) 


CALL instruction 
and not a far (inter-segment) 


CALL instruction. 


The comments 
at the beginning 
of the module 


and 
adjacent 
to 
the 
program 
statements 
ex- 


plain 
the 
function 
being 
performed 
by 
the 


assembly language code. 


The SBCCO Module 
@ The console output 
procedure 
CO is contained 


in the object module 
SBCCO of the library 
file 


SBCIOS.LIB. 
SBCIOS.LIB 
is pan 
of the iSBC 


957 package I/O 
libraries. The calling sequence 


and 
parameters 
for 
CO 
may 
be seen 
in. the 


external 
procedure 
declaration 
in 
the 
EXE- 


CUTION$VEHICLE 
module. 


Compiling 
the EXECUTION$VEHICLE 
Module 


The EXECUTION$VEHICLE 
module is stored on 


a file named 
MATRIX.PLM 
on disk device :FI:. 


To compile 
the module, 
the 
following 
command 


line is used: 


- PLM86 
:FI:MATRIX.PLM 
DEBUG 


This command 
line will cause the module stored in 


the file :FI :MATRIX.PLM 
to be compiled. 
The 


object code generated 
will be stored 
in a file with 


the default name :FI :MATRIX.OBJ 
and the listing 


generated 
will be stored 
in a file with the default 


name 
:FI :MATRIX.LST. 
To override 
the default 


object and listing files, the NOOBJECT 
and NO- 


LIST compiler 
control 
switches can be used. 
File 


names for the listing and object 
files may also be 


specified in the command 
line. The 
DEBUG 
com- 


piler control switch causes the compiler to generate 
extra 
symbol 
and 
line number 
information 
which 


will be used during 
debugging 
of the program. 
A 


listing 
of the compiled 
EXECUTION$VEHICLE 


module is contained 
in Appendix 
B. 


To 
aid 
in 
the 
debugging 
of 
the 
program, 
the 


module 
was compiled 
a second 
time with the fol- 


lowing command 
line: 


- PLM86 
:Fl:MATRIX.PLM 
NOOBJECT 
CODE DEBUG PRINT (:Fl :MATRIX.XLS) 


This command 
line specified that no object file is to 
be created and a listing file should be stored in the 
file :Fl:MATRIXXLS. 
The CODE 
compiler 
con- 


trol switch causes the compiler 
to list the assembly 
language 
statements 
which the compiler 
has gener- 


ated for each line of PL/M 
code. The listing stored 


in the file MATRIXXLS 
is contained 
in Appendix 


C. 


Assembly of the FIND Module 


The assembly language module FIND is stored on a 
file named 
FIND.ASM, 
to assemble 
this module 


the following command 
line is used: 


ASM86 :Fl :FIND.ASM 
DEBUG 


This command 
line will cause the FIND module to 


be assembled 
with 
the object 
code 
stored 
in the 


default 
file :Fl :FIND.OBJ 
and the listing stored in 


the default 
file :FI :FIND.LST. 
The listing of the 
assembled 
FIND 
module 
is contained 
in Appendix 
B. 


Linking and Locating the Object Module 


To link and locate the object modules, 
the QRL86 


program 
will be used. The 
QRL86 
program 
per- 


forms 
both 
the 
linking 
and 
the 
locating 
of 
the 
object modules in a single step. QRL86 is primarily 
designed for the debugging stages of program 
devel- 


opment. Some applications 
may require the extended 


capabilities 
of the separate 
LINK 
and 
LOCATE 


programs 
when 
the final 
link and 
locate 
is per- 


formed. 
The 
command 
line 
used 
to 
invoke 
the 


QRL86 program 
is: 


QRL86 :Fl :MATRIX.OBJ, 
:Fl :FIND.OBJ, 


SBCIOS.LIB 
ORIGIN 
(lOOOH) 


This command 
line will cause QRL86 
to link the 


code 
from 
the 
three 
modules 
and 
to 
locate 
the 


resultant absolute object module starting at location 
1000 hexadecimal. 
The iSBC 86/12 
monitor 
uses 


the first 
180H bytes of memory 
for the monitor 


stack, data and interrupt 
vectors, lOOOHwas chosen 


as a convenient 
starting 
address 
for the program. 
The absolute 
object code will be stored in a default 


file :Fl:MATRIX 
(note no file name 
extension 
is 
used). 
By default, 
the memory 
and 
debug 
maps 
which are generated 
are stored in the file :Fl:MA- 


TRIX.MPQ 
and are contained 
in Appendix 
B. 
® The 
memory 
map 
contains 
the 
starting 
ad- 


dresses 
and 
sizes 
of 
the 
CODE, 
CONST, 
DATA, 
STACK 
and 
MEMORY 
segments 
of 


the object module. 
Note that the start address 


for the program 
is specified as ~l~H, 
~2H) 


indicating 
a CS value 
of ~1~H 
and 
an 
IP 
value of ~2H 
or an absolute value of 01~2H. 


The first two bytes of the code segment contain 
address values which the code generated 
by the 


compiler 
will use for setting up the DS and SS 


registers. 
The 
memory 
map 
shows 
the 
code 


segments from the three modules 
collected into 


the group 
CGROUP. 
The code segment 
from 
the EXECUTION$VEHICLE 
module 
is given 


the segment 
and class names 
of CODE 
and is 


put into CGROUP 
by the PL/M 
compiler. 
To 


assure 
that 
the code segment 
from 
the FIND 
module 
is concatenated 
with the code segment 


from the EXECUTION$VEHICLE 
module the 


identical 
class, segment and group 
names were 


specified in the SEGMENT 
and GROUP 
state- 


ments 
in the FIND 
module. 
Next, 
the group 


DGROUP 
is 
shown 
in 
the 
memory 
map. 


DGROUP 
contains 
4 
segments 
labelled 


CONST, 
DATA, 
STACK 
and 
MEMORY. 


Putting all of these segments in the same group 
tells the linker that they will all be in the same 
64K block of memory. 
The SMALL 
size con- 


trol option 
of the compiler, 
which was invoked 


by default, 
creates 
CGROUP, 
DGROUP, 
and 


the segments contained 
in them. 
® The debug map 
contains 
the memory 
address 


of 
variables, 
instruction 
labels 
and 
the 
ad- 


dresses 
of 
each 
code 
line 
of 
the 
PL/M-86 


module. 
Notice that the variable 
storage 
labels 


have their addresses specified in the format 
(DS 


register value, displacement). 
For example, 
the 


variable TEMP 
has an address of DS=~12AH, 


displacement 
= m<:H 
or an absolute 
address 


of ~136H. 
Instruction 
labels and line numbers 


use the format 
(CS register 
value, 
IP register 
value). Thus, line number 
six (6) in the module 


EXECUTION$VEHICLE 
has 
the 
address 


CS=~I~H, 
IP=~B5H 
or ~IIB5H. 


Object to Hex Conversion 


Before downloading 
the program to the iSBC 86/12, 


the format of the object module must be converted 
.from 
the 
absolute 
object 
module 
format 
which 


QRL86 creates to a hexadecimal! ASCII representa- 
tion of the object module. This is done using the pro- 
gram OH86 with the following command 
line: 


OH86 :FI:MATRIX 
TO :FI:MATRIX.HEX 


Downloading 
and Debugging the Program 


The hardware 
configuration 
used for debugging 
the 


matrix 
multiplication 
example 
program 
code 
was 


an Intellec 
Series II Model 
230 development 
sys- 


tem, the iSBC 957 package, 
an iSBC 86/12 
board, 


and an iSBC 660 system chassis. 
What 
follows 
is 
the 
system-user 
dialog 
for 
a 
typical 
debugging 


session. 


The 
first 
step 
required 
is to 
bootstrap 
load 
the 
ISIS-II 
operating 
system 
by 
hitting 
the 
RESET 


switch of the Intellec. 
The Intellec resident 
loader 


software 
is then loaded 
and executed. 
Throughout 
the dialog 
which follows 
operator 
entered 
charac- 


ters will be underlined: 


ISIS-II, 
V3.4 
-58C861 


ISIS-II 
lsac 
86/12 
LOADER,VI.2 


To initialize the iSBC 86/12 
monitor, 
the user must 
hit the RESET switch on the iSBC 660 chassis and 
type two "U"s 
on the system console. The monitor 


program 
will output 
a line on the console when it is 


properly initialized. 


The monitor 
command 
"X" 
is typed to check that 


the monitor 
is properly 
operating 
and to examine 


the contents of the 8086 registers . 


. x 
AX::"""" 
BX=-000d 
CX=I:l000 
DX=lHhhJ 
SP=01C0 
Bp:000" 
51=00130 


!:H:c00Ihi 
C5:881:10 DS:::IHHhl 
SS=0[}00 
ES=kHI00 
Ip:"000 
FL:0000 


To 
download 
the 
hex 
object 
file 
to 
the 
iSBC 


86/12, 
the 
"L" 
command 
is used. 
Because 
an 
Intellec Series II Model 230 is being used, a serial 
download 
is 
specified. 
The 
hex 
file 
name 
is 


MATRIX.HEX 
which 
is resident 
on disk 
device 


:FI:. 


The "X" 
command 
is used again to examine 
the 


CPU registers. 
Note that the monitor 
has changed 


the contents 
of the CS and IP registers to the value 
of the starting address of the program. 


.~ 
AX=IHHHl 
eX:::"""0 
CX:::I'HHJ0 
DX::iH:l~" 
SP=01Ci:1 
BP=0000 
51;0000 


01::0000 
CS=0HHI 
OS:::0""'0 
55=0o"o 
E:S:0000 
IP=0002 
FL=0000 


The "D" 
command 
is next used to display the first 
101 bytes of the program 
code. Unless another 
seg- 
ment 
register 
is specified, 
the 
display 
command 


assumes all addresses specified are relative to the CS 
register. Thus, the code displayed will be from ab~o- 
lute addresses 1000 through 
1100. The program code 
displayed may be compared 
with program code gen- 


erated by the PL/M-86 
compiler shown in Appendix 


C, code line 36. 


. 00 1~0 
0{;-;iT.2A0.l 
Ai 
:: 16 
,,~~ 
r 
oJ 
i1~ lJB foe 
l~ 
IF 
Fe. 


021£; 
C7 
~6 
BE 
00 
00 
eo 
81 
3E 
BE 
00 
05 
00 
7E 
03 
E:9 
)C 


~020 
00 
C7 06 
:to 00 
1';1 ~I:t 
&1 
3E 90 
'HI 04 eo 
7E 03 
t::9 


• 
0039 
22 
20 
88 
06 
~E 
J0 
B9 
0A 
"" 
P7 
E9 
as 
3690 
00 
OJ 


0040 
E6 
89 
C3 
BB 
BE 
BE 
90 
89 
a8 
10 
00 
81 
06 
90 
00 
01 
1:l05~ 
00 
E9 
03 
FF 
dl 
06 
BE 
00 
01 
08 
E9 
89 
FF 
C7 
"6 
BE 


09613 00 
90 
~0 81 
3E BE 00 
H4 
90 
7E ~3 
E9 
4" 
00 C7 06 


0070 
90 
00 
00 
00 
B1 3E 90 
00 
02 
00 
7E 03 
E9 26 
0\J 88 
0080 
06 
90 
00 
F7 
08 
50 8B 06 
BE 00 
B9 06 
00 
F7 E9 BB 


0090 
36 90 00 01 E6 89 C3 59 89 88 
4~ 00 
81 06 90 00 


D0A0 01 
90 
E9 CF FF a1 
06 
8E 00 
01 
00 
E9 B5 FF C7 06 


\!l0B" 
92 
00 
00 
00 
81 
3E 92 
~0 02 
00 
7E 03 
E9 BC 00 
C7 


00C0 
06 
8E 00 
00 
00 
81 
3E 8E 00 
05 
00 
7E 03 
E9 72 
00 


0000 
B8 06 
8E 00 
89 
06 
00 
F'7 E9 88 
36 
92 
00 01 
E6 89 


00E0 
C3 C7 80 
6A 00 
00 
01' 
C7 06 
90 
00 
01' 
00 
81 
3E 90 


0eFe 
00 
04 
00 
7E 
03 
£9 
41 
00 
88 
06 
8E 
00 
B9 
0A 
00 
F7 


0lRJ0 
E9 


The PL/M-86 
compiler 
ends the main program 
in 


the EXECUTION$VEHICLE 
module 
with a halt 


instruction. 
After 
execution 
of the 
program 
it is 


more 
desirable 
to return 
to the monitor. 
To 
ac- 


complish 
this, 
an 
INT 
3 instruction 
(code=CC) 


will be substituted 
for the halt instruction 
(code= 


F4) at the address 
of IB4H relative to a CS value 


of lOOH. First the "D" 
command 
is used to verify 


the address 
of the halt instruction, 
then the "S" 


command 
is used to change 
the instruction 
to an 


INT 3 instruction. 


.0184 
0lB4F'4 
.~ 
F4- 
Q; 


To execute the PL/M-86 
main program, 
the "G" 


command 
is used. 
After 
the 
"G" 
is typed, 
the 


current 
contents 
of the IP are output, 
followed 
by 


the contents 
of the byte pointed 
to by the IP. 
A 


new value for the IP or breakpoint 
addresses 
may 


be 'specified before a carriage return 
<CR> is typed. 


In this example, only a <CR> is typed. 


.Ii 
0002- 
FA 
MA.X V,\LUE 
=- 
-00'150 


@IU00:"1B5 
55 


The program 
executes 
and outputs 
the maximum 


value of the matrix 
calculated. 
The INT 3 instruc- 


tion 
is 
executed 
which 
causes 
a 
return 
to 
the 


monitor. 
The 
monitor 
types 
out 
an 
at-sign 
(@) 


followed 
by the CS and IP register values and the 


first byte of the instruction 
following 
the INT 
3 


instruction. 


The "X" 
command 
is typed to examine 
the CPU 


registers. Note that the program 
has set both the SS 


and DS registers to ~12A. (~12A~H is the address 
of the DGROUP 
as shown in the memory map.) 


• X 
AX:1:l030 BX:0005 
CX~000A 
OX"'0000 5P=00D0 
BP=0000 
51=0001 


Dl:0006 
C5"'1I100 
D5:012A 
5S=012A 
E5:00130 
IP=IHB5 
FL:P202 


display 
has 
been 
specified 
by using 
the 
"DW" 


Command 
and that the addresses 
have been speci- 
fied relative 
to the DS register. 
The addresses 
of 


X$ROW, 
Y$ROW, 
and Z$ROW 
may be found in 


the debug 
map 
given by QRL86. 
Note 
that 
the 


values stored in the matrices 
are the same as those 


shown in Figures 8 and 9. 


.ow 
DS:10,4A 
0010 
0iHl0 0~00 
0H0~ 
0800 
IhUl0 0001 
0001 
tl0lU 
""20 
1t091 0001 
0002 
0002 
9002 
0002 
A002 0003 


0030 
0\103 0003 
!te03 
1:1""3 0004 
0904 
0004 
0004 


EHl40 0004 
001'5 
0005 
0095 
0005 
1'005 


.ow 
05:4(,68 
0~4C 
'HH~0 
FFFF 


111050 
FFFE 
e0~0 
FFPF 
FFFE: 
0bl:l0 
FFFF 
FFFE 
0000 
1:1060 
FFFF 
FFFE 
0000 
FFF'F 
FFFE 
• Dw D$: 6A, Be 
iHl6A 
~hHj0 
iji:l00 
001U, 


0070 
0000 
PFFB 
FFF6 
0000 
FFF6 
FFEe 
00{10 
FFf'l 


1:J080 
FFE2 
0001:1 
FFEe 
FfOB 
01HHl 
PFE? 
FFeE 


The "G" 
Command 
is used to reset the IP register 


to the start 
address 
of the program 
(f1IJ2) and to 


specify a breakpoint 
at address ~AEH, 
which is the 


address 
of 
statement 
57 of 
the 
main 
program. 
Statement 
57 is the point in the program 
after the 


X$ROW 
and 
Y$ROW 
matrices 
have been initial- 


ized, 
but 
before 
the 
matrix 
multiplication 
is 
performed. 
After the <CR> is typed, 
the program 


executes 
until 
the 
breakpoint 
is encountered. 
At 


this point, 
the monitor 
outputs 
a line specifying 


the 
number 
of 
the 
breakpoint, 
the 
CS 
and 
IP 


values and the first byte of the ne~t instruction 
to 


be executed. 


.§ 0185- 
55 0e2,A£ 


BRI 
@0100:00AE 
C7 


Next, 
the 
single-step 
capability 
is used 
with 
the 


"N" 
command 
to execute 
single instructions. 
At 


any 
time, 
CPU 
registers 
may 
be 
examined 
or 


changed. 
In this example, 
the 
"X" 
command 
is 
used. Execution 
of succeeding instructions 
is caused 


by typing a comma (,). 


.~ 
IHIAE- 
C7 
..l. 
I"'B4- 81 , 
0BaA- 
7£ 
~ 
00BF- 
C7 
- 
.~ 
AX""I:ll:tlB 
BX=1:J018 
eX-FFYE 
DX:00iJ0 
SP=00D0 
I3P=0000 
51=IH1001 


01=0006 
C5=0100 
D$"'012A 
SS::012A 
ES=0lHI0 IP=00BF 
FL::t"293 
.H 
0~BE"- 
C7 
, 


kJ0C5- 
81 
, 
- 
kJ~CB- 
7E 
- 


The contents of the X$ROW 
and Y$ROW matrices 


are examined 
and 
changed 
with the 
"SW" 
(sub- 


stitute 
word) 
command. 
If a comma 
(,) is typed 


after 
the contents 
of memory 
are displayed, 
then 


the contents 
are left unchanged 
and the next word 


of memory 
is displayed. 
If a value followed 
by a 
comma 
or <CR> is entered, 
then the contents 
are 


changed. 
If 
a 
<CR> 
is entered, 
the 
substitute 


e~1co~m~ 
~m- 1 


BIiJlE 
BIHlIl- 
10 


.SW DS:5A. 
ITPF- 
~ 


SB5e 
FPFE- 
, 


0B5E 
0BilB- 
~ 
~060 
FFFF- 
~ 


After 
the 
matrices 
are 
modified, 
execution 
is 


resumed with the "G" 
command. 
The max value is 


output 
and the INT 3 instruction 
executed. 
Finally, 


the contents of the 3 matrices are displayed. 


•.9. 00C8- 
7E 
MAX 
VALUE:: 
+00430 


@lt100:0185 
55 
• OW os: 10, 
8e 
0010 
0000 
0000 
0000 
0000 
0000 
0001 
01HH 
0013 


0020 
0001 
0001 
0002 
00D2 
0002 
01::102 0002 
0003 


0030 
0003 
0003 
0003 
0003 
0ili::l4 
0D04 
0004 
001;ll4 
0040 
0004 
0005 
0005 
0005 
0e05 
1'005 
01100 
FFFF 


0850 
FFFE 
0000 
FFFF 
fFFE 
0000 
FFFF 
FFFE 
00110 


~060 
0064 
FFFE 
01::100 FFFF 
FFFE 
0000 
0008 
00013 


0870 
0000 
01'51 
FF08 
01::101' 00e0 
FFEe 
0iBl0 
IH20 


0080 
PFE2 
0000 
0180 
FF08 
0000 
01E0 
.FPCE 


Expanding 
the Example Program's 


Memory Requirements 


To illustrate 
how the iSBC 86112 
board 
may be 


used 
for 
executing 
8086 programs 
which 
require 


large amounts 
of RAM, 
the example program 
will 


be modified. 
The matrix dimensions 
of the example 


will be changed 
from values of 6, 5 and 3 for the 


literal symbols 
of M, N, and P to values of 100, 


50, 70. The 
three 
matrices 
will then 
be of 
size 


lOOX50, 50X70, 
and 
lOOX70. The 
memory 
re- 


quired 
for these matrices 
is 15.5K words 
or 3IK 


bytes. 
The 
data, 
constant, 
stack 
and 
memory 


segments 
which 
are 
contained 
in 
the 
group 


DGROUP 
will now comprise 
almost 
32K bytes of 


memory. 


The extra 
memory 
requirements 
will be supplied 


by using an iSBC 032 board 
with the iSBC 86/12 


board in the iSBC 660 chassis. The iSBC 032 board 
is a 32K byte 
RAM 
board 
which 
is compatible 


with 
both 
8- and 
16-bit CPU 
boards. 
The 
base 


address 
of the board 
may be selected anywhere 
in 


a 0 to 1 megabyte range on any 16K byte boundary. 
8- or 
16-bit data 
transfers 
may 
be selected. 
The 


iSBC 032 board 
will be jumpered 
to respond 
to 


addresses 
in the 512K or 544K address 
space 
(20 


bit hex address range to 8(Y/X/XIJH to 87FFFH). 
This 


will illustrate 
the capabilities 
of the 8086 to access 


a 20-bit, I megabyte address range. 


One other modification 
is required 
to the program. 


The magnitude 
of the numbers 
which would result 


from multiplying 
matrices 
of this size would great- 
ly exceed the capacity 
of the 16-bit integer storage, 


even with the two matrices 
initialized 
to the small 


values they presently 
contain. 
To keep the example 


simple, 
the initialization 
values will be changed 
so 
all elements of the X$ROW 
matrix are set equal to, 


2 and all elements 
of the Y$ROW 
matrix 
are set 
equal to 3. The result of the multiplication 
should 
make all the elements of Z$ROW equal to 300. 


The 
modified 
lines 
of 
program 
code 
are 
shown 
below. 


1* 
MATRIX 
DI~ENSIONS, 
*/ 
DECLARE 
M LITERALLY 
'HUl'; 


DECLARE 
N 
LITERALLY 
'50'; 


DECLARE 
P 
LITERALLY 
'70'; 


36 
DO I 
= 
~ 
TO 
(M-l); 


37 
DO J 
= 
0 
TO 
(N-I); 
38 
X$ROW(I).COL(J) 
2; 
39 
END; 
40 
END; 


41 
DOI=0TO(N-l); 
42 
DO J 
= 
0 
TO 
(P-l); 


43 
YSROW(I) 
.COL(J) 
3; 
44 
END; 


45 
END; 


The EXECUTION$VEHICLE 
module 
must be re- 


compiled and then the three program 
modules must 
be linked 
and located 
using the QRL86 
program. 
Specifying the SEGMENTS 
option 
of QRL86, 
the 
origin of the CODE segment which is in the group 
CGROUP 
is set at 1OOOH, as in the first example. 


However, 
the 
origin 
of 
the 
CONST, 
DATA 


STACK 
and MEMORY 
segments 
which make 
up 


the group DGROUP 
is set at 80000H. 


QRL86 :F1 :MATRIX.OBJ 
,:F1 :FIND.OBJ, 
SBC10S.LIB 
SEGMENTS 
(CODE(lOOOH), 
CONST (80000H), DATA STACK, MEMORY) 


The memory 
map generated 
by QRL86 
shows the 


CGROUP 
having 
a start 
address 
of 01000H 
and 


the DGROUP 
having a start address of 80000H. 


INVOKED 
BY: 
QRL86 
:Pl:'1A'rRIY.OBJ,:Fl:FINO.OBJ,SBCIOs.LIB 
Ii 


SEGMENTS (CODE (l00it") 
,CONST 
(80000H) 
, DATA ,STACK 
,ME"lORY) 


INPUT 
MODULES INCLUDED: 


: FI: 
'1ATq.r 
Y. OBJ 
(EXECUTIONVEHICLE) 


: F1: 
FIND.09J 
(FIrW) 
38CIOS. 
LIB (sacco) 


3TART 
LTH 
.ALIGN 
NAME 
CLASS 


01i:l00H 
298H 
G 
IGS/ 
CGROUP 
01000~i 
21DH 
" 
CODE 
(EXECUTIONVEHICLE) 
CODE 
01210H 
41H 
B 
CODE 
(FIND) 
CODE 
'0125EH 
)AH 
w 
CODE (saCCo) 
CODE 
ICEI 
CGROUP 
860~0H 
7970H 
G 
lesl 
OCROUP 
80~Hl0H 
CH 
W 
CONST (EXECUTIONVEHICLE) 
CONST 
8000CH 
0H 
w 
CONs'r 
(SBCCO) 
CONST 
8000CH 
792AH 
w 
DATA (EXECUTIONVEHICLE) 
DATA 
87936H 
2H 
W 
DATA (FIND) 
DATil, 
87938H 
0H 
w 
DA'r,~(sacco) 
DATA 


ij7940H 
)0H 
sw 
STACK 
ST,br.CK 


87970H 
0H 
w 
MEMORY 
~EMORY 


ICEI 
DCROiJP 
87970H 
0H 
G 
??SEG 
(FIND) 
(NULL) 


The object 
code is then converted 
to hex format 


and downloaded 
to the iSBC 86/12 
board. 
When 


the 
program 
is executed, 
the 
maximum 
value 
is 


calculated and output 
on the console. 


-SBCBG1 


ISIS-ll 
ISBC 
86/12 
LOADER, 
VI.2 


Isac 
86/12 
MONITOR"V1.2 


• LS, 
: E"l: MATRI Y. HEX 


.~ 
P4- 
<;f 
.G 
0002- 
FA. 


MAX 
VALUE:: 
+00300 


@~10~: 01AO 
55 


VI. CONCLUSION 


This application 
note has described 
the iSBC 957 


Intellec-iSBC 
86/12 
Interface 
and 
Execution 


Package, 
and 
how 
this package 
may 
be used 
to 


develop and debug programs 
for the 8086 ",rocessor. 


First, 
the iSBC 86/12 
single board 
computer 
was 


described, 
followed by a detailed description 
of the 


iSBC 
957 package 
and 
the 
iSBC 
86/12 
system 


monitor 
commands. 
The power 
and versatility 
of 


the iSBC 957 package 
and monitor 
commands 
for 


developing 
and debugging 
programs 
for the 8086 


were 
illustrated 
by a 
program 
example. 
In 
the 


example 
a program 
which consisted 
of PL/M-86 


and assembly language routines was presented. 
The 


program 
code was explained, 
and the steps required 


to compile, 
assemble, 
link, 
locate, 
and 
debug 
the 


program 
were 
illustrated. 
Finally, 
a 
typical 
de- 
bugging session using the iSBC 86/12 
system moni- 
tor which illustrates the powerful 
capabilities 
of the 


monitor 
was presented. 
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APPENDIX 
B 


PROGRAM 
LISTINGS 
FOR EXECUTION$VEHICLE 
AND FIND MODULES 


® 


10 
II 
© 


12 
)) 
I' 


15 
lfi 
17 
lP 
19 
20 
21 


" 
'n 
®{ 
/:4 
25 
2. 


27 
'" 
29 


PL/1'I-86 
MAIN 
PROGRAM 
WHICH: 


A) 
INITIALIZES 
TWO 
INTEGER 
I'IATRICES 
B} 
MULTIPLIES 
THE 
TWO 
MATRICES 
AND 
STORES 
TliE 
RESULT 
IN 
A 


THIRD 
MATRIX 
t:) 
CALLS 
AN 
ASSEMBLY 
L,II,NGUAGE 
PRGef.DURE 
WfHCH 
SEARCHES 
THE 
THIRD 
MATRIX 
FOR 
THE 
MAXIMUM 
V.b.LUE 
0) 
CALLS 
A 
PL/M 
PROCEDURE 
WHICH 
CONVERTS 
THE 
MAXIMUM 
VALUE 
FROM 
INTEGER 
TO 
ASCI 
I 
E) 
CALLS 
]J 
PROCEDURE 
WHICli 
OUTPUTS 
THE 
ASCII 
CHARACTERS 
ON 
THE 
SYSTEM 
CONSOLE 


lit 
FIND~MX 
- 
EXTERNAL 
ASSf.MBL'i 
LA.NGUAGE 
PRQCEflURF 
WHICH 
SEI>.RCI1ES 
A 
MATRIX 
FOR 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 
PARAI-IETERS: 


MATRIxS".DR 
- 
ADDRESS 
OF 
THE 
~ATRIX 
TO 
Rf. 
SEARCHED 
ROWS 
- 
NUMBER 
OF 
ROWS 
IN 
THE 
MATRIX 
COL<; 
- 
NUMBER 
OF COLUMNS 
IN 
THE 
M"rRIX 
'j 
F'TND$MX: 
PROCEDURE 
(MATRIX$PTR, 
RG\oiS, 
COLS) 
INTEGER 
EXTERNAL; 
DECLARE 
(ROWS, 
COLS) 
INTEGE:R; 
DECLARE: 
MATRTXSPTR 
POINTER; 


END 
FINDSMX; 


/* 
BIN$DEC$ASC 
- 
BINARY 
TO 
DF'CJMAL 
ASCI 
T 
CONVERSION 
PI10CEDURE 
PARAMF:TERS: 


VALUF: 
- 
INTEGER 
V,A.LUF 
'l'0 
BE 
CONVERTf,D 
TO 
ASCTI 
CHARSARRI\Y$ADR 
- 
II.DDRP-ss 
Of 
6 
BYTE 
ARRAY 
I'JHERE 
ASCI 
r 
STRING 
CONTAINING 
THE 
VALUE 
l'iILL 
BE 
STORED 


DECLARE 
(VALUE, 
TEMP, 
I) 
INTEGER; 
DECLARE 
CI-lARSP.,RR.A.YSADR 
POINTER; 
DECLARE 
(CHARSARRAY 
BASED 
CH"RSARRA'f~ADR) 
(6) 
BYTE; 


I F 
VALUE 
< 
e 
THEN 
DO; 


CHARSARRAY/~) 
'" 
1* 
SIGN 
CHAR/ICTER 
*/ 
TEMP'" 
-VALUE; 
END; 
ELSE 
DO; 
CH!lR~ARnAY(p) 
"" 
'+'; 
TEMP"" 
VALUE; 


E~D; 
DO T 
"" 
5 
TO 
1 
BY 
-1; 


CHARSARRAY(!) 
"" 
UNSIGN/TEMP 
MOD 
1(\) 
+ 
3f:H; 
TP.ro'IP '" 
TEMPI] 
r; 


1* 
ASCII 
CHARACTERS 
?il 
THRU 
19 
HEX 
REPRESENT 
THE' 
DIGITS 
~ 
THRU 
9. 
THUS 


TO 
CONVERT 
AN 
INTEGER 
TO 
ASCII 
REPE.A.TF.D 
DIVISIONS 
BY 
](1 
AND 
ADDING 
THE 
REMAINDER 
TO 
?r, 
HEX 
WILL 
ACCOMPLJSH 
THE 
CONVERSION 
*1 
END; 
. 


1* 
CO 
- 
EXTERNAL 
PROCEDURE 
'ro 
OUTPUT 
A 
CHARACTER 
TO 
THE 
SYSTEM 
CONSOLE. 
THIS 
PROCEDURE 
IS 
PART 
OF 
THE 
TSBC 
957 
LIBR/I.RY 
FOR 
CONSOLE 
I/O 


PARAMETER: 


CHAR 
- 
ASCII 
CHARACTER 
TO 
BE 
OUTPUT 
ON 
THE 
CONSOLE 


'j 
CO: 
PF:OCEDURE· 
(CHAR) 
EXTERNJI,L; 
DF:Cl.ARE 
CHAR 
PYTE; 


END 
CO; 


/* 
MATRIX 
D!.I'oIJENSIONS 
*1 
DECLARE 
M 
LITERALLY 
'Ij'; 


DECl.ARE 
N 
LITERALLY 
'5'; 
DECLARE 
P 
LrTERAl.LY 
'J'; 


1* 
THE 
THREE 
MATRICFS 
ARE 
DECLARsn 
AS 
ARHAYS 
OF' 
STRUCTURES. 
X$ROW 
IS 
COMPOSED 
OF 
M STRUCTURES 
EAOI 
OF 
WHICH 
IS 
COMPOSED 
OF 
N 
INTEGER 
ELEMENTS. 
THUS 
X$ROW 
MAY 
BE 
THOUGHT 
OF 
AS 
A 
M 
X 
N 
MATRIX, 
THE 
MATRIX 
WILL 
BE 
STORED 
AS 
A 
RO\o!-ORDER 
MATRI 
X WITH 
THE 
ELEMENTS 
OF' 
EACH 
ROW STORED 
IN 
ADJACENT 
MEMORY 
LOr.ATIONS. 
YSROW 
IS 
DECLARED 
AS 
A 
N 
X 
P 
MATRIX 
AND 
Z$ROW 
AS 
A 
N 
X 
P 
Ml\TRIX 
*/ 


DECLARE 
X$ROW{M) 
STRUCTURE 
(COLIN) 
INTEGER); 


OECLARE 
Y$ROW(N) 
STRUCTURE 
(COL (P) 
INTEGER); 


DECLARE 
Z$ROW(M) 
STRUCTURE 
(COL{P) 
INTEGER); 


DECLARE 
(I,J,K,MAX) 
INTEGER; 
DECLARE 
MAXS,A.SC$ARRAY 
(h) 
BYTE; 
DECLARE 
TF:XT 
(*) 
BYTf 
DATA 
('MAX 
VALUE'" 
'); 


36 
37 
J~ 
39 


® 


'e 


41 
4> 
4J 
<4 
'5 


©{ 


46 
'7 
'8 
'9 
50 
5l 
52 
53 
@ 
5. 


® 


55 


®{ 


50 
57 
5. 


59 
6e 
61 


62 


/* 
INITr.a.LIZE 
XSROW 
SUCH 
THAT 
THE 
FJRST 
ROW 
IS 
SET 
EQUAt 
TO 
e, 
THE 
SECOND 
ROW 
EQUAL 
TO 
1, 
THE 
THIRD 
R()\I,' 
EQUAL 
TO 
2, 
ETC. 
*/ 
DO I'" 
PI 
TO 
(M-!); 


DO J 
= 
V TO 
(!II-I); 
X$RQW(I).-eOL(J) 
=. 
Ii 
END; 
END; 


/* 
INITIALIZE 
Y$ROW' 
SUCH 
THAT 
THE 
FIRST 
COLUMN 
IS 
SET 
EQUAL 
TO 
A, 
THE 


SECOND 
COLUMN 
EQUAL 
TO 
-I, 
AND 
THE 
THIRD 
COl.UfII1N 
EQUAl. 
TO 
-7.. 
*/ 


DO 
I 
:::: e 
TO 
(N-l); 


DO J 
'" 
pi 
TO 
(P-l); 


Y$ROW(I).C'OLfJ) 
'" 
-J; 
END; 


£NO; 
/. 
PERFORM 
MATRIX 
MULTIPLICATION 
*; 
DO 
K 
'" 
~ 
TO 
(P-l); 


DO 
I 
= 
~ 
TO 
(M-l); 


Z$ROW(I).COL{I<") 
:::~; 
/* 
SET 
Z$RQW 
ELEMENT 
TO 
'" 
"'/ 


DO J 
= r 
TO 
(N-l); 
/* 
SUM 
THE 
PRODUCT 
or 
XSROW 
ROW TERMS 
AND 
YSROW 
COLUMN 
TERMS 
*/ 


Z$ROWtI) 
.COL(K) 
= 
Z$ROW(l) 
.COl.{K) 
+ 
( 
X$ROW(I) 
.CQ( .•(J) 
.• Y$RQWIJ) 
.COL(KI 
); 
END; 


END; 


END; 


DO 
I 
= 
" 
TO 
(SIGNED(SIZE(T£XT) 
- 
,1); 
1* 
OUTPUT 
HEADER 
TEXT 
?I 
CALL 
COITEXT(I)); 


END: 


DO I 
:: 
~ TO 
5; 
1* 
OUTPUT 
ASCII 
MAX VALUE 
*1 


CALL 
CO(MAX$ASC$1-.RRAYII)); 
END; 


CODE AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
z 


VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
S TZE 
1.17 
LINES 
READ 
" 
P..ROGRAMERROR (S) 


END OF 
PL/M-86 
COMPI LATION 


0225H 
Ai?'CK'H 
npgnH 
""HleH 


ISIS-II 
MCS-86 
ASSEMBLER 
ASSEMBLY 
OF MODULE 
FIND 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:FIND.OBJ 
ASSEMBLER 
INVOKED 
BY: 
ASM86 
: F 1: FIND. 
ASM DEBUG 


LOC 
oeJ 


FINDMX 
ASSEMBLY 
LANGUAGE 
PROCEDURE TO 
FIND 
THE 
ELEMENT 
OF AN 
INTEGER 


MATRIX 
WITH 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 
THE 
VALUE 
OF THE 


ELEMENT 
IS 
RETURNED 
IN 
THE 
AX 
REGISTER. 


PARAMETERS: 


ADRSOF$MATRIX 
- 
ADDRESS 
OF THE 
MATRIX 
WHICH 
WILL 
BE 
SEARCHED 


,$OF$ROWS 
- 
NUMBER OF 
ROWS IN 
THE 
MATRIX 
,$OF$COLS 
- 
NUMBER 
OF COLUMNS 
IN 
THE 
MATRIX 


PL/M 
WILL 
PASS 
THE 
THREE 
PARAMETERS 
IN 
THE 
CALL 
TO THIS 
PROCEDURE ON 


THE 
STACK. 
ON ENTRY 
TO 
THE 
PROCEDURE SP-+-6 WILL 
POINT 
TO THE 
FIRST 


PARAMETER (ADR$OFSMATRIX) 
AND 
SP-+-4 AND 
SP-+-2 WILL 
POINT 
TO THE 
SECOND 


AND 
THI~D 
PARAMETERS. 


THE 
PROCEDURE 
IS 
A TYPED 
PROCEDURE WHICH 
ASSIGNS 
THE 
MAXIMUM 
VALUE 


IN 
THE 
MATRIX 
TO 
A 
VARIABLE 
(IN 
THIS 
CASE 
MAX$VALUE) 
IN 
A 
PL/M 
ASSIGNMENT 
STATEMENT. 
TO ACCOMPLISH 
THIS 
ASSIGNMENT 
THE 
VALUE 
IS 


RETURNED 
IN 
THE 
AX 
REGISTER. 


THE 
ALGORITHM 
USED 
IS 
SIMILAR 
TO THE 
FOLLOWING 
PL/M 
CODE: 
FOR 
I 
:: 
0 
TO 
(,$OFSROWS 
- 
1); 


FOR J 
:: 
" 
TO 
(,$OFSCOLS 
- 
1); 
IF 
IABS(MATRIX(I}.Y(J)} 
> 
IABS(MAX) 
THEN 
MAX 
== 
MATRIX(I).Y(J); 
END; 
END: 


LOC 
OBJ 


0{ 
0{ 
~00~ 
"1"400 


®{ 


BP"P 
<" 
P.P"" 


) 


BBB. 
II 
00"4 
f 1 
0~08 
[1 


0?0e 
peee 
55 
"''''01 
SBEe 
"Bill) 
3302 
PASS 
BBF'A 
see? 
eBF2 
2'009 
89160000 
""00 
884£04 


"'010 
OlEI 


"'012 
PBSEP8 


© 


~"15 
ABee 


"A17 
0BC0 
~\ll19 
79912 


(>Hl1B 
F7D8 
(HHO 
3aC? 
~"l F 
7C07 
?1Ii21 
BBN' 


e"'2) 
EHH,e 


?f"25 
A)"0ee 
"'028 
83C602 
11"'28 
)BF'I 
0020 
72£6 
J"'2F 
~D18 
r'~31 
BE"""" 
::'03'" 
47 
l7'035 
387£06 
0038 
7208 


003A 
A10""" 
0"30 
50 


003£ 
C2A600 


DEFINE 
GROUPS 
TO 
CONFORM 
WITH 
PL/M-86 
CONVENTIONS. 
DATA, 
STACK, 
AND 


CODE 
SEGMENTS 
WILL 
BE 
APPENDED 
TO 
THEIR 
RESPECTIVE 
SEGMENTS 
IN 
THE 


PL/M-86 
MODULES. 


GROUP 
DATA, 
STACK 
GROUP 
CODE 


INSTRUCT 
THE 
ASSEMBLER 
THAT 
THE 
OS, 
55, 
AND 
CS 
REGISTERS 
WILL 
CONTAIN 


THE 
BASE 
ADDRESS 
VALUES 
FOR 
THE 
DGROUP, 
DGROUP 
AND 
CGROUP 
GROUPS. 
ASSUME 
OS: DGROUP, 
55: 
DGRQUP ,es: CGROUP 


DATA 
SEGMENT 
WORD PUBLIC 
'D"T'" 
MAX 
OW 
0 


D"T/\ 
ENDS 


~PARAMETERS 
ON 


NO OF 
ROWS 
NO~OF-COLS 
AD'R"_OF"_M"TRIX 


STACK, 
DISPLACEMENT 
FROM TOS 
INCREASED 
BY 
TWO DUE 
TO 
INITIAL 
PUSH 


EQU 
WORD PTR 
[BP+6] 
EQU 
WORD PTR 
[BPH] 
EOU 
WORD PTR 
(BP+8] 


;TERMINATION 
FOR J (51) 
INDEX 


BX,ADR_OF_M"TRIX 
;AOR$OF$M"TRIX 
PARAMETER 


;BX 
POINTS 
TO 
FIRST 
ELEMENT 
OF 
" 
GIVEN 
ROW 


GET 
ELEMENT 
OF 
MATRI X 


SET 
FLAGS 
JUMP 
IF 
SIGN 
= 
0 


NEGATE 
TO 
FORM 
POSITIVE 
NUMBER 


COMPARE 
TO 
CURRENT 
MAX 
JUMP 
I F 
LESS 
THAN 
CURRENT 
MAX 


MOVE TO 
ABS 
OF CURRENT 
MAX 


MOVE MATRIX 
VALUE 
TO 
CURRENT 
MAX 


NEAR 
BP 
BP,SP 


OX, 
OX 
DI,DX 
SI,OX 
MAX ,OX 
CX,NO 
OF 
COL5 
CX,I 
- 
- 


; PROCEDURE 
DECLARATION 


;SAVE 
BP 
REGISTER 


; BP 
POINTS 
TO 
PARAMETERS 
ON STACK 


; SET 
OX 
= 
ABS 
OF CURRENT 
MAX 
'" 
0 


;01 
'" 
I (ROW INDEX) 
= 
0 
;51 
:: J (COLUMN 
INDEX) 
= 
0 


; MAX 
= 
CURRENT 
MAX 
= 
e 


INCREMENT 
J 
INDEX 
BY 
TWO 


END OF 
THIS 
ROW?? 


IF 
NO, 
LOOP 
BACK 
FOR 
NEXT 
ELEMENT 
OF 
THIS 
ROw 
BX 
= 
BX 
+ 
(2 
,.. '$OF$COL5), 
BX 
POINTS 
TO 
NEXT 
RQ\Il 


J 
= 
0 


I 
'" 
I 
+ 
1 
LAST 
ROW?? 


IF 
NO, 
DO THE 
NEXT 
ROW 
RETURN 
MAX 
VALUE 
IN 
AX 
REGISTER 


RESTORE 
BP 
REG ISTER 
INCREMENT 
SP 
BY 
6 
AND 
RETURN 
TO 
CALLER 


AX, 
[BX} 
[SIJ 
AX, 
AX 


DEF 
AX 
AX ,OX 
XYZ 
OX, 
AX.... 


AX, 
[BX] 
[SIJ 
MAX ,AX 
51,2 
SI,CX 
ABC 
BX, 
fBX+Sl] 
SI,0 
01 
DI,NO 
OF 
f.lOWS 


ABC 
AX,MAX 
BP 
6 


SYMBOL 
TABLE 
LISTING 


N/\ME 
TYPE 
VALUE 
ATTRIBUTES 


??SEG 
SEGMENT 
SIZE=0~0"H 
PARA 
PUBLIC 
ABC 
L 
NEAR 
~015H 
CODE 


ADR 
OF 
MATRIX 
V WORD 
00eaH 
IBPI 


CGROUP-;- 
GROUP 
CODE 


CODE. 
SEGMENT 
SIZE=0041H 
BYTE 
PUBLIC 
'CODE' 


DATA. 
SEGMENT 
SIZE=0'HI2H 
WORD 
PUBLIC 
'DATA' 


OEF 
L 
NEAR 
P0lDH 
CODE 


DGROUP. 
GROUP 
DATA 
STACK 


FlNDMX. 
L 
NEAR 
ee00H 
CODE 
PUBLIC 
"AX 
V WORD 
e000H 
DATA 


NO OF 
COLS. 
V WORD 
0004H 
[BP) 
NO-OF-RO~S. 
v 
WORD 
~006H 
fBP} 
STACK- 
SEGMENT 
SIZE=('0lCH 
PARA 
STACK 
'STACK' 


XY2 
L NEAR 
0028H 
CODE 


INVOKED 
RY: 


(lRLA'" 
: F) : MATRI 
X. OBJ, 
: F) 
: FIND. 
OBJ, 
saCIOS. 
LIB 
ORTC I N (J "p,rH) 


INPUT 
MODULES 
INCLUDED: 
: Fl 
: MATRIX.OBJ 
fF.XfCUTTONVEHICLE 
1 


: F 1: FIND. 
OBJ 
(FIND) 
SBC JOS. 
LIB 
(SBCCO) 


@ 


START 
LTH 
ALIGN 
NA/'IE 
CLASS 


~190P,H 
7M!H 
G 
/GS/ 
CGROUP 


P10e0H 
:?2SH 
w 
CODE (EXECllTlONVEHICLE~ 
CODE 


01225H 
"H 
• 
CODE 
(FIND) 
CODE 
r12fi6H 
~'&'H 
'. 


CQDE (SBCCO) 
CODE 
/GE/ 
CGROUP 
012M"H 
DOH 
G 
/GS/ 
DGROUP 
e12A0H 
CH 
w 
CaNST 
(EXECUTIONVEH 
ICLE) 
CaNST 
f012ACH 
OH 
W 
CONST 
(S eacco 1 
CONST 


0121>.CH 
nH 
w 
DATA (EXECUTION 
VEHICLE 
) 
DATA 
0133CH 
2" 
'" 


DATA(FIND) 
DATA 
e13~EH 
OH 
w 
OAT A (SBCCO) 
DATA 
0134PJH 
.10H 
SW 
STACK 
STACK 
~1370H 
0" 
W 
MEMORY 
MEMORY 


/GE/ 
DGROUP 
• 
370H 
OH 
G 
??SEG 
(FIND) 
(NULL) 


DEBUG 
Ml\P 
OF 
: Fl: 
MATRIX 
(EXECUTIONVEIlICLE) 


MODULE: 
EXECUTTONVEHICLE 
01e-0H,01E1H 
LINE ., 
19 
e-H'eH,£'13S'H 
LINE 
I, 
51 


1312AH, 
e0DOH 
SYMBOL 
MEMORY 
~1,""r.H,01FBH 
UNE 
" 


2O 
~HHltl,r.142H 
LINE 
! 
53 


Ill] "~H, 
1".]B5H 
SYMBOL 
BINDECASC 
AHH1H,PJ21 
~H 
LINE .' " 


0J00fl,P11~ElH 
LINE 
• 
5' 


P12AH,IH~"CH 
SYMBOl 
TEMP 
I"lAPlH,P'21EH 
LINE 
t, 
22 
01B0H, 
1"l5EH 
LINE 
I 
5> 
A12AH, 
P~"'EH 
SYMBOL 
I 
010~H,022IH 
LINE 
t, 
23 
,n~eH,r]r,9H 
LINE 
t 
5fi 
P'l1AH,VA10H 
SYMBOL 
XRO\N 
('IUlH,r,e02H 
LINE 
" 


3fi 
P.le0H,BI71o.H 
LINE 
I 
57 


~12AH,P104CH 
SYMROL 
VROW 
I"I~0H,0e'-IH 
LINE 
t, 
37 
1"10eH,0185H 
LINE 
t 
58 
~ 121o.H, eA6AH 
SYMBOL 
ZROW 
(110AH, 
P'A32H 
LINE 
" ,. 
011H'H,I'U8EH 
LINE 
l 
<;9 


® 


017AH,0~8EH 
SYMBOL 
I 
~IIH~H,00.1BH 
LINE " '" 


Cl)(H:'lH,rJ9FH 
LINE 
t 
6. 


'J121lH, 
~09rH 
SYfolBOL 
J 
eH!0H,A~5ilH 
UNE 
ff' 
'0 
"HH!H, 
V-IAAH 
LINE , 
OJ 
(1] 21o.H, Al"92H 
SYMBOL 
K 
plr"H,11!05DH 
LINE 
" " 


(' 1017'H, 
I"-lB3H 
LINE , 
62 


r12AH,re9.1lH 
SYMBOL 
MAX 
r I veH, 
refiEH 
LINE 
" 
'7 
MODULE 
FIN 
Al :?1o.H,llIA9"H 
SYMBOL 
MAXASCARRA 
Y 
01{\AH,0P7FH 
LINE 
t 
'3 
0100H,023AH 
SYMBOL 
ABC 
~'l12AH, 
VBe(llH 
SYMBOL 
TEXT 
V IP'PH, 
~09CH 
LJNE 
t •• 
0190H, 
e'242H 
SYMBOL 
DEF 
0UPH,PIB5H 
LINE 
t 
6 
AIP0H,£IPASH 
LINE 
t 
'5 
0109H,0225H 
SYMBOL 
FINDMX 


?100H, 
POIBRH 
LINE 
I 
I' 
0U0H, 
"'0AEH 
LINE , 
'fi 
912AH,909CH 
SYMBOL 
MAX 


Pl~P'H,"lC2H 
LINE 
I 
12 
P1Je0H,0eBFH 
LINE 
t 
47 
0100H,024DH 
SYMBOL 
xvz 


Al"I"H, 
AICSH 
LINE 
I 
IJ 
0Ie0H,0BDPH 
LINE , 'e 
0IeOH,0225H 
PUBLIC 
FINDMX 


AIP!PH,l;:)O)H 
LINE 
t " 


l"Hl0H,P'AE7H 
LINE 
t 
'9 
MODULE 
SBCCO 


e10BH,~ID4H 
LTNE 
t 
lfi 
AI0BH,0AFBH 
LINE 
t 
50 
U"0H,0266H 
PUBLIC 
CO 


Plll1PH,0lDAH 
LINE • 
17 
l"JClrH,01.'U!H 
LINE 
t 
51 


ISIS-II 
PL!M-86 
VI." 
COMPILATION 
OF 
MODULE 
EXECUTIONVEHICLE 
NO OBJECT 
MODULE 
REQUESTED 
COMPILER 
INVOKED 
BY: 
PLMBfi 
:Fl:MATRIX.PU'" 
DEBUG 
CODE 
NOOBJECT 
PRINTf:F1:MATRIX.XLS) 


PL!M-36 
MAIN 
PROGRAM WHICH: 
A) 
INITIALIZES 
TWO INTEGER 
MATRICES 


B) 
MULTIPLIES 
THE 
TWO MATRICES 
AND 
STORES 
THE 
RESULT 
IN 
A 
THIRD 
MATRIX 
C) 
CALLS 
AN ASSEMBLY 
LANGUr..GF: PROCEDURE 
'••••HICH 
SEARCHES 
THE 
THIRD 
MATRIX 
FOR 
THE 
MAXIMUM 
VALUE 
D) 
CALLS 
A 
PL/M 
PROCEDURE 
••••HICH 
CONVERTS 
THE 
"lAXIMUM 
VALUE 


FROM 
INTEGER 
TO 
ASCI I 
E) 
CALLS 
A 
PROCEDURE 
WHICH 
OUTPUTS 
THE 
ASCI I 
CHARACTERS 
ON 
THE 
SYSTEM 
CONSOLE 


II< 
rTND$I'IX 
- 
EXTERNAL 
ASSEMBLY 
LANCUAGE 
PROCEDURF: WHICH 
SEARCHES 
A 


MATRIX 
FOR 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 
PARAMETERS: 
MATRIX$ADR 
- 
ADD.RESS 
OF THE 
MATRIX 
TO 
BE 
SEARCHED 


RO',oJS- 
NUMBER 
OF 
ROWS IN 
THE 
f'\ATRIX 


COLS 
- 
NUMBER 
OF' COLUMNS 
IN 
THE 
MATRIX 
'/ 
F'INO$MX: 
PROCEDURE 
(MATRIX$PTR, 
ROWS, 
COL~) 
INTEGER 
EXTERNAL; 
DECLARE 
(ROWS, 
CO(5) 
INTEGER; 


DECLARE 
MATRIX$PTR 
POINTER; 


END 
FIND$MX; 


II< 
BIN$DEC~ASC 
- 
BINARY 
TO 
DECIMAL 
ASCII 
CONVERSION 
PROCEDURE 
PARA"1F:TERS: 


VJ!.LUE 
- 
INTECER 
VALUE 
TO 
BE 
CONVERTED 
TO 
ASCII 


CHAR$ARRAY$AOR 
- 
ADDRESS 
OF 
G BYTE 
ARRAY 
WHERE ASCI I 


STRING 
CONTAINING 
THE 
VALUE 
\JILL 
BE 
STORED 


B INDECASC 


PUSH 
MOV 


'/ 
BINSDEC$ASC: 
PROCEDURE 
(VALUE, 
CHARSARRAY$A.DR); 


STATEMENT 
_ 
., 


PROC NEAR 
BP 
BP, SP 


DECLARE 
(VALUE, 
TEMP, 
I) 
INTEGER; 
DECLARE 
CHARSARRAVSADR 
POINTER; 
DECLARE 
(CHARS"RR"Y 
BASED 
CHARSARRAY$ADR) 
(6) 
BYTE; 


"lBR 
817E060""" 
CMP 


"'IBD 
7C03 
JL 


f'lBF 
E912~~ 
JMP 
DO; 


CHAR SARRA Y ("') 
'_ 
I • 


fl1C2 
88SE9'4 
MC'V 


0ICS 
C50770 
folOV 
TEMP'" 
-VALUE; 


C1Cf! 
8B4/)06 
MOV 


cnCB 
F'7D8 
NEG 


r lCD 
1l9ftfiP"C'" 
MOV 
END; 


ELSE 
00; 


CHAR$ARRA yell' 
I 


ClD~ 
8BSEP( 


0107 
C6P72B 
TEMP'" 
VALUE; 


(1J OJ!. 
8B<1'>116 


?IDD 
890(jI1P~~ 


F.:ND; 


r 1E1 
C7{t6P2"(\0sne 


C1E7 
E~P'6re 


@3, 


01EA 
8.1l?,f\02P'PPFFF 


; 
STATEMENT 
f 
10 
fBP). 
VALUE, 
r.H 


$+5H 


@l 


1* 
SIGN 
CHARJ!..CTER *! 


; 
STATEMENT 
~ 
J 2 


BX, fBPI.CHARARRI\YADR 
CHARI\RRAY 
[BX], 
2DH 


; 
STATEMENT 
II 
1) 


AX, 
fBP]. 
VALUE 
AX 
TEMP,AX 


; 
STATEMENT 
• 
Iii 


BX, 
r BPI. 
CHARARRAYADR 


C"HARARRAY rBX 1, 7BH 


; 
STATEf"IENT 
, 
1 7 
AX,[BP1.VALUE 
TEMP, l'X 


liaS: 


rlFe 
ElI3Ef'i'eBP'lI'J0 


Q'1PI) 
70e3 
IUFa 
E9261"P 


CHARSARRAY 
(I) 


C'MP 
I, 
JH 
JG£ 
S+SH 
JMP 
fl4 
UNSIGN 
(TEMP 
MOD 
11') 
+ 
3PH; 
; 
STATEMENT 
, 
i'~ 
8BP'f5~000 
B90Ap.e 
3102 
F7F9 
RJCi'3e0P1 
88SEf14 
88360200 
881P 
TEMP:: 
TEMP/U; 


AX, TEMP 
CX, BAH 
OX ,OX 
CX 
DX,3f1H 


ax, 
(BPj.CHARARRAYAOR 


51, I 


raxJ. 
CHARARRAY fSI}, 
DL 


; 
STATEMENT 
t 
21 


/* 
ASCtI 
CHARACTERS 
30 
THRU 
39 
HEX 
R£PRESENT 
THE 
DIGITS" 
THRU 
9. 
THUS 


TO 
CONVERT 
AN 
INTEGER 
TO 
ASCII 
REPEATED 
DIVISIONS 
BY 
U 
AND 
ADDING 
THE 
REMAINDER 
TO 
3e 
HEX 
WILL 
ACCOMPLISH 
THE 
CONVERSION 
*/ 
r213 
Ba"60e"0 
MOV 
AX, TEMP 
0211 
99 
CWO 
0218 
F7F9 
IDIV 
cx 
021A 
8901j00f10 
MOV 
TEMP,AX 


END; 


0221 
'iD 
POP 
I3P 


"227. 
C2A4"H' 
RF.T 
4H 
AINDECASC 
ENDP 


1* 
CO 
- 
EXTERNAL 
PROCEDURE 
TO 
OUTPUT 
A 
CHflRAC1'ER 
TO 
THE 
SYSTEM 
CONSOLE. 


THIS 
PROCEDURE 
IS 
PART 
OF 
THE 
IsaC 
9~7 
LIBRARY 
FOR 
COfllSOLE 
IlO 
PARAMETER: 


CHAR 
- 
ASCI 
I 
CHARACTER 
TO 
BE 
OUTPUT 
ON THE 
CONSOLE 
'j 
('0: 
PROCF:OURE 
ICHAR) 
EXTERNt\L; 


DECLARE 
CHAR 
BYTE; 


END CO; 


/* 
MATRIX 
DIMENSIONS 
./ 
DECLARE"l 
LITERALLY 
'(-'; 


DECLARE 
N 
LITERALLY'S'; 


DECLARf 
P 
LITF-RALLY 
')'; 


/. 
THE 
THRE!:: 
MATRICES 
ARE 
DECLARED 
AS 
ARRAYS 
OF 
STRUCTURES. 
X$RQW' IS 
COMPOSED 
OF 
M STRUCTURES 
EACH 
OF 
WHICl-! 
IS 
COMPOSED 
OF 
N 
INTEGER 
ELEMENTS. 
THUS 
X$Ro.-J 
MAY 
AE 
THOUGHT 
OF 
AS 
A 
M X 
N 
MATRIX. 
THE 
MATRIX 
WILL 
BE 
STORED 
AS 
A 
RCW-ORDER 
MATRIX 
WITH 
THE 
ELEMENTS 
OF 
EACH 
ROW STORED 
IN 
ADJACENT 
MEMORY 


LOCATIONS. 
Y$RIJW 
IS 
OECLARED 
AS 
A 
N 
X 
P 
MATRIX 
AND 
Z$ROW 
AS 
II 
N 
X 
P"1ATRIX 
./ 


r:'ECLI',RE 
XSROW(M) 
STRurTURE 
{COL (I'll 
INTEGER); 


OF-CLARE 
Y$ROW(N} 
STRUCTURE 
(COL(Pl 
INTEGER); 


DECLARE 
Z$ROW(M) 
STRUCTURE 
(COL (P) 
INTEGER); 


DECLARE 
(I"J,K,MAX) 
INTEGER; 


DEC"L,ARE M,AX$ASCSARRAY (~l 
BYTE; 


DECLARE 
TEXT I·) 
eYTE 
OATA 
('/OIAX 
VALUE 
'); 


/. 
INITIALIZE 
X~ROW SUCH 
THAT 
THE 
FIRST 
ROW IS 
SET 
EQUAL 
TO 
, 
THE 
SECOND 
ROW EOUAL 
TO 
1, 
THE 
TH I RD 
RQloI EQUAL 
TO 
2, 
ETC. 
• / 
DO 1= 
0 TO 
fM-I); 


flPl92 
fA 
eLl 
"'09]- 
2E8F160flPP 
MOV 
SS ,CS: 
f@STACK$FRAME 
r'H~f! 
BC0B~0 
MOV 
SP,@@STACK$OFFSET 
0fl1f1B 
BBEC 
MOV 
BP,SP 


0000 
16 
PUSH 
SS 
0~0E 
1F 
POP 
os 
"""OF 
FB 
STI 
~0U 
C7068i'0PH':l000 
Mev 
I, 
VH 


H' 


0016 
813E82PH!V50P1 
CMP 
I, 
SH 


r.P1JC 
7El'l) 
~1LE 
$+5H 
""01 E 
E93C"~ 
JMP 
e? 


DO 
J 
= 
• 
TO 
(N-l) 
; 
; 
STATEMENT 
I " 
0V'.1 
C:~684Q10'HHH: 
MOV 
J,0H 
PP: 


0~27 
81 3E840p1B4P'~ 
CMP 
.l,4H 


0020 
7EP'3 
,TLE 
$+511 
r02F 
E9220" 
.]MP 
P9 


JP 
X$ROW(I).COLfJ) 
= I; 
; 
STfl.TE"lENT 
I 
'SO 
f"PJ2 
ABMB21"O 
Mev 
AX, I 


P<ft3fi 
BorACH' 
MOV 
cx, 
rAH 


rll':l39 
F7E9 
[MUL 
ex 


APJR 
8B.16849" 
MOV 
ST ,,1 
~lnF 
D1EF; 
S""L 
51,1 


"""I 
A9C3 
MOV 
ex,AX 
"043 
flBj?!E82CH' 
MOV 
cx, 
J 
r~"'7 
891:18""4""1' 
Mev 
rBX 1. XROW[51 j ,CX 


19 
END; 


5-84 
AFN-01931A 


STATEMENT 
i 
39 
~fl""B 
el~"R4N·PrJ0e 
'00 
J,lH 
?,flSl 
E~o3FF 
JMP 
eR 


@~ 
: 


'0 
END; 
S1'ATE!"IENT 
! 40 
pr.sd 
RU'r,e20~01PO 
ADD 
I,] 
H 
ProsA 
E989FF 
JMP 
PO 


iii?: 


/1< 
JNITIALTZE 
't'$ROW 
SUCH 
THAT 
THE 
FIRST 
COLUMN 
IS 
SET 
EOUAL 
TO 
0, 
THE 


SECOND 
COLUMN 
EQUAL 
TO 
-], 
AND 
THE 
THIRD 
COLU/'lN 
EQUAL 
TO 
-2. 
*/ 
00 
I 
:. 
ill TO 
(N-l); 


0050 
e70682PJV{II{IIN" 
MOV 
[, 
{IIH 


flIP: 


fJ?'63 
813E820004PJP 
CMP 
[,4H 
0e69 
7El3:? 
JLE 
$+sH 


lHHlB 
E94l300 
JMP 
pll 
42 
DO 
J 
:. 
l3 TO 
(P-l) 
; 


; 
STA.TEMENT 
I 
42 
DPl6E 
C706840000P'PJ 
MOV 
J, 
PH 
@12: 


0074 
813E8400PJ20l3 
CMP 
J,2H 


007A 
7E03 
JLE 
$+sH 
007C 
E926l3P 
JMP 
@13 
" 


Y$ROW" ([) 
• COL (J) 
:. 
-J; 


STATEMENT 
! '3 


007F 
flB068400 
MOV 
AX,J 


0083 
F708 
NEG 
AX 


0085 
5. 
PUSH 
AX 
; 
l 


0086 
880682139 
MOV 
AX, 
I 
0eBA 
B90fie0 
MOV 
CX,6H 


BA80 
F7E9 
[MUL 
CX 
0"8F 
8836B400 
MOV 
SI,J 


"093 
olEf; 
SHL 
51,1 
N19s 
89C3 
MOV 
BX,AX 
0"97 
59 
POP 
CX 
1 
"'PI98 
89884000 
MOV 
rBX 1. YROW rs I} 
,CX 


" 
END; 
; 
STA.TEMENT 
! " 
IH'I9C 
8Hl684~"elP" 
ADD 
J .1H 


0AA2 
E9CFFF 
JMP 
~l> 
Fl13: 


45 
E~o; 
STATEMENT 
f 
45 
APlAs 
AH~"82P0eI0r 
ADD 
1,1H 
rHMB 
E9R')f"F 
JMP 
.,. 


@ll: 
;" 
PERFORM 
MATRIX 
~ULTl:PLJr.A.TJDN 
"; 
,r, 
DO 
K 
• 
• 
TO 
(P-l) 
; 


l"f'AE 
C'A"8"i00M'0P 
MOV 
PH: 


Vl1B4 
e 13ERSftV0200 
CMP 
~li'BA 
7E'~3 
JLF: 


flPBC 
E9€cr('l 
JMP 


co 
[ 
= o 
TO 
(M-J) 
; 


(H'BF 
C:7('liP;=verpcp' 
MOV 


"16: 


r~cs 
p J 3E~J~"P'5f'·(l 
("~P 
rrCB 
7E~1 
JL~ 
~0CO 
En2rr 
JMP 


'8 
Z$ROW(I) 
.COL(K) 
= f'; 


Ol"D'l 
PBVf>S2Cf1 
MOV 


1"004 
BQ?6pr 
MOV 
PP.07 
F7Eq 
IMUL 
NW9 
flB)li86""" 
MOV 
r~DD 
olE6 
SHL 


~~DF 
1l9C1 
MOV 
"""El 
C7f!l"5E0P./lA'H' 
MOV 
49 
00 
J 
:. 
P 
TO 
(N-l) 
; ;" 


APE7 
r.7e684M'APPPI 
,.ov 
f112: 


peED 
913EBIl~Vn.1re 
CMP 


"AF! 
?Eft3 
JLE 


"~Fs 
E~ll] 
00 
JMP 
,. 
Z$ROW(I) 
.COL(K} 
= 


(lAF8 
Si806821H! 
MOV 
~AFC 
B9PAllr, 
MOV 
00FF 
F7E9 
1HUL 
0101 
883684"'" 
MOV 


011"5 
ol 
Efi 
SHL 


('II P7 
5. 
PUSH 


01~8 
8806840!lJ 
MOV 


iJIPC 
~9960e 
MOV 


AUF 
F7E9 
IMUL 


0111 
883E860r 
MOV 
PllS 
OJ E7 
SHL 


~117 
89C3 
MOV 


\ll119 
8B81HHl0 
MOV 
"'lID 
5B 
POP 


9llE 
F7A8A400 
1MUL 


"'127 
5. 
PUSH 


3123 
880682"'0 
MOV 
1"127 
F7E9 
IMUL 
P129 
8ge) 
MOV 


I. 
<;H 
~-+-5H 


"1)7 


/" 
SET 
ZSROW 
ELE~ENT 
TO 
r */ 


; 
STA'rEfIlENT 
3 
48 
AX, 
I 


CX, 
"H 
cx 
51, K 
S1,1 
OX,l\X 
fSX).ZROwrS1l.rH 
SUM 
THE 
PRODUCT 
OF 
X$ROW 
RQ\<' TEH"'IS 
AND 
't'$ROW 
COLUMN 
TER"lS 
* / 


; 
STATEMENT 
I 
49 


J,01H 
$+5H 
@19 
Z$ROW(I).COL(K) 
+ 
r 
X~ROW(I).COL(J) 
* 
't'$ROW(J).COL(K} 
}; 


; 
STATE"'IENT 
I 
51'1 
AX, 
I 
cx, VAH 
ex 
51.J 
$1,1 
~.X 
; 
1 


AX.J 
cx, fiH 
cx 
01, K 
01.1 
ex, AX 
AX, 
rBX]. 
't'ROWr01 
1 
ax 
; 
1 
faX]. 
XRDW [SI 
1 


AX 
; 
1 
"X, I 
ex 
ex ,AX 


pl) 28 
58 
POP 
AX 
1 


Ql12C 
n81SEV" 
ADD 
rex) 
• ZRO".' [Dr) 
, ,A.X 


51 
ENI); 


; 
STl\TEMENT 
I 5] 


"130 
810ll8tlPC0HH" 
ADD 
J,IH 


013'i 
E9B.I!FF 
JMP 
e] 8 


@J9: 


52 
END; 


STATEMENT 
I 52 
~139 
8JIlI'iP20V010~ 
ADO 
r,lH 


01 )F 
E983FF 
JMP 
e" 
fill7: 


5) 
END; 
; 
STATEMENT 
I 
53 
~142 
8H~68fiOJ~0le'r, 
ADD 
1<.,1H 


Vi lilfl 
E9"9FF 
JMP 
." 
flll:: 


5' 
MAX .FINDSMX 
r~Z~ROw, 
M. 
P) ; /. 
FIND 
MAX 
VALUE 
OF 
Z$ROW ./ 
; 
STATEMENT 
t 
5' 


III1118 
885E0P 
Mev 
AX,OFFSETfZROW) 
PHE 
5" 
PUSH 
AX 
1 


~1.dF 
88~f'N' 
_OV 
!IX, 
flH 


~152 
5' 
PUSH 
AX 


015 ~ 
BflV3~r. 
MOV 
AX,3H 


PI] 5" 
5r 
PUSH 
AX 


A157 
E8€l:"pr 
CALL 
F INDMX 


01SA 
8906881H) 
MOV 
"t!lX, 
AX 


55 
C,ALL 
8IN$DEC$ASC 
(MAX, 
filMAX$ASCS.A.RRAYj; 
It< 
CONVERT 
TO 
DECIMAL 
ASCII 
./ 


; 
STATEMENT 
I 
55 


131SE 
FF3fi8000 
PUSH 
MAX 
1 


01fi2 
88flAPl0 
MOV 
AX, OFFSET (MAXASCARRAY) 
~165 
5' 
PUSH 
AX 
2 
P1166 
E84C0~ 
CALL 
BINDECASC 


"!fi9 
C70682P000VA 
MOV 
1,0H 
@20: 


016F 
PI )EP20{'0B00 
CMP 
I. 
"8H 


0175 
7E03 
JLE 
S+5H 


0177 
E914~OJ 
JMP 
@2] 
57 
CALL 
CC'(TEXT{I)); 


STA'PEMENT 
I 
57 
P17A 
flBIE8200 
MOV 
BX, I 


017E 
FFB70APHI 
PUSH 
TEXT rBX}; 
1 


~182 
E800"" 
CALL' 
co 
58 
END; 


STATEMENT 
I 
58 


0185 
8lP,6C2~00lA0 
ADD 
I, 
JH 


A1BS 
F:9EIFF 
JMP 
Pl' 
~21 : 


59 
DO I 
= 
~ TO 
5; 
/. 
OUTPUT 
ASCII 
MAX 
VALUE ./ 
; 
STATEMENT 
t 
59 


VileE 
C106R2'HHHl"''' 
MOV 
I, rH 


1iI22: 


0194 
813Ee2000~'H) 
CMP 
J,5H 


019'A 
7El" 3 
JLE 
$+5H 


019C 
E9J41l1e 
JMP 
fil2) 


fiP. 
CALL 
CO f 1'lAX$A5CSARRAY 
I r) 
) ; 


~19F 
eBIE~:?~P- 


~]A3 
FFB'7BAP-e 


~IA7 
E:801100 
END; 


eJJIo.A 
810fi82e0"Je" 


"'I8A 
E9EIFF 


CODE 
A.REA. SIZE 


CONSTANT 
AREA 
SIZE 
VARIABLE 
"REA 
SIZE 
MAXIMUM 
STACK 
SIZE 


137 
LINES 
READ 
" 
PROGRAM ERROR (5) 


'" 
0225H 
000CH 
009BH 
'" 
IHJBBH 


INTRODUCTION 


Companies seeking to develop microcomputer 
appli- 
cations are faced with two significant problems. First, 
applications are growing more and more sophisticated. 
With competition 
always present, 
products 
are con- 


tinually being enhanced with new features. This bur- 
dens the underlying 
computer 
system by increasing 
both the complexity of the software and the number of 
events 
and functions 
that 
must be handled 
by the 
system. 


The second problem is a management 
problem. These 
newer 
and 
more sophisticated 
application 
systems 
must be developed quickly in order to hit shrinking 
market windows. Also, they must be developed with 
lower manpower costs to be feasible in an engineering 
community struck by insufficient 
technical personnel 
and skyrocketing software development costs. 


These are the needs addressed by the iRMX 86™ Oper- 
ating System. The two goals in the development of this 
product have been power/flexibility 
to meet th~ needs 
of increasingly complex application systems, and ease 
of understanding 
and use, to boost the productivity 
of 
available engineering resources. Users of Intel's line of 
iSBC 86™ Single Board Computers or custom-designed 
8086-00800 boards can now obtain the same benefits 
from Intel supplied system software as they can from 
Intel supplied system hardware. 


The reader of this application 
note is provided with 
information in four subject areas. 


• 
The requirements 
of operating 
systems 
are 
discussed along with traditional solutions. 


• 
The iRMX 86 Operating 
System is introduced 
and its features are discussed in relation to the 
requirements 
studied earlier. 


• 
System design using the iRMX 86 Operating 
System is studied using example solutions. 
• 
Code for two example systems is examined to 
learn the details of system implementation. 


Some of the topics in this note may not be of interest 
to all readers. For example, an experienced real-time 
programmer may not need to read the entire overview 
of real-time systems. For those who want to brush up 
on a few topics, the overview is organized to allow the 
reader to focus attention on areas of specific interest. 


Throughout 
this application 
note, various terms and 


concepts 
are 
introduced 
and 
discussed. 
If further 
information 
on any of these 
topics is desired, 
the 
references listed in the front of this note should be 
used. 


This overview is provided to investigate both the prob- 
lems encountered 
in the design of applications 
soft· 


ware and also the classical solutions to these problems. 


Multitasking 


A real-time 
system is defined 
to be a system 
that 


reacts to events occurring external 
to the computer 


and which monitors or controls these events as they 
occur (or in "real-time"). The converse of a real-time 
system is known as a batch system where the outcome 
of a program does not depend on when it is run (for 
example, a payroll program). 


Two other characteristics 
typically encountered 
in a 


real-time system are asynchronous 
event occurrences 


and concurrent 
activity. 
The first 
characteristic 
is 


caused by events occurring randomly rather 
than at 


scheduled 
intervals. 
The second characteristic, 
con- 


current activity, takes place when two or more events 
occur nearly at the same time, requiring simultaneous 
activity. 


One method of dealing with the requirements 
of a 


real-time system would be to write a program 
that 


knows 
what 
events 
could 
potentially 
occur 
(for 


example, an interrupt 
occurrence, 
a real-time 
clock 


counting 
down 
to zero, a byte 
in memory 
being 


modified by another 
program). 
This program 
could 


then execute a large loop checking for the occurrence 
of these events. 


There are several problems with this approach. While 
processing one event which has occurred, the program 
is 
not 
responsive 
to 
other 
events. 
Also, 
the 


programmer has no way of prioritizing the importance 
of the various events. From a maintenance standpoint, 
this program is complex and difficult to enhance or 
modify. 


The traditional 
solution to these problems is a tech- 


nique called multitasking. 
Essentially, 
this involves 


writing many small routines instead of one large one. 
Each of these routines (tasks) can process events in- 
dependent 
of the other tasks in the system. In addi- 


tion, a priority can be assigned each task so that the 
operating 
system can decide as to which task is the 


most important 
when more than one task requests 


control of the CPU. 


The support 
for multitasking 
involves 
a scheduler 


which is part of the service provided by the operating 
system. The scheduler allows each task to execute its 
program as if it has sole control of the CPU, ensuring 
that all tasks desiring CPU time are serviced accordmg 
to the priority associated with each task. 


From the standpoint 
of system design, multitasking 


has many desirable 
qualities. 
Large and potentially 


complex application programs can be decomposed into 
smaller more manageable 
units. This makes feasible 
the use of programmer 
teams to implement the appli- 


cation. Perhaps even more importantly, 
the potential- 
ly overwhelming problems surrounding concurrent exe- 
cution and interrupt 
handling become transparent 
to 


the 
application 
programmer. 
Also, 
multitasking 


makes 
the 
modification 
of existing 
tasks 
and 
the 


addition of new ones become a manageable 
objective 


since the interaction between tasks is minimized. 


Interrupt Handling 


A common event in a real-time system is the occur- 
rence of an interrupt. 
Because this event is so com- 


mon, an important 
feature 
of a real-time operating 


system is its interrupt 
processing capabilities. 


From the standpoint of application software, interrupt 
handling can be cumbersome. The currently 
running 


task must be preempted, 
various hardware 
devices 


must be manipulated 
and perhaps a hardware 
inter- 


rupt controller must be dealt with. 


A real-time operating 
system can abstract 
the occur- 
rence of an interrupt 
into something more consistent 


with the way other events are handled. A task can 
simply inform the scheduler that it does not require 
any CPU time until an interrupt 
occurs. The relative 


priority of different 
interrupts 
can also be handled in 


the same manner as the priority of multiple tasks are 
handled. Thus, the application programmer 
need only 


deal with the actual processing 
related to interrupt 


occurrence. 


Reliability 


Reliability is a keyword in all real-time systems. In 
this type of system, reliability does not refer to mean 
time between failure. In fact, the software in a real- 
time application 
typically cannot be allowed to fail. 


The difficulty 
impojled on the software 
by the en- 


vironment 
comes from the near infinite 
number 
of 


permutations 
that can occur. A system that appears to 


be fully debugged can fail in the field because of a 
combination 
of 
simultaneous 
events 
that 
never 


occurred before. 


The only means to avoid failure in these instances is 
through 
the 
use of a consistent, 
well-thought-out 


model for handling events. Any special-cased solution 
is subject to failure when the special cases that were 
designed for are violated in the real world. 


Error handling 
can also add reliability 
to an appli- 


cation 
system. 
When 
the 
application 
software 
is 


unable to anticipate the outcome of certain conditions, 
or the software has undiscovered bugs, it is vital for 
the operating system to gracefully handle the situation 
and allow for further processing to continue as best as 
possible. 


1/0 Handling 


Many applications for 16-bit microcomputers require a 
variety 
of I/O devices. The support 
for I/O opera- 


tions on these devices is typically 
provided 
by the 


operating system. Both sequential access and random 
access devices are typically encountered 
and, in addi- 


tion, flexibility in handling I/O requests and acknowl- 
edgements is important. 


The flexibility necessary typically involves the sched- 
uling of a task's execution after an I/O request has been 
made. The greatest 
flexibility can be obtained by an 


asynchronous I/O system. In this system, a task makes 
an I/O request by calling the operating system. Once 
the processing of the request 
has begun, control is 


returned to the calling task. 


In this manner, 
the task can continue executing its 


program while the I/O operation is progressing. When 
the results of the operation are desired, the task can 
call the operating 
system again to wait for the com- 


pletion of the previous I/O request. 


The second type of I/O support is less flexible but also 
easier to use. An operating system that supports syn· 
chronous I/O allows a task to make a single operating 
system call to make an I/O request. 
Once control is 


returned 
to the calling 
task, 
the 
I/O operation 
is 


complete and the results 
are immediately 
available. 


This type of I/O support sometimes takes advantage of 
a technique known as autobuffering 
to regain some of 


the 
performance 
advantage 
of the 
overlapped 
I/O 


found in the asynchronous system. 


Debug Support 


The inherent 
characteristics 
of the real-time environ- 


ment sometimes make it difficult to debug new soft- 
ware. If the simultaneous 
occurrence 
of two events 


causes a bug in the software, detection may be difficult 
because the next time the system is run the error is not 
reproduced. Also, because of the fact that the software 
is broken down into many independent 
tasks, the in- 


teraction 
may be difficult 
to track 
using standard 


debugging techniques. 


The solution to these problems is a piece of software 
called the system debugger. 
The debugger 
typically 


has three characteristics. 


1) It is designed to interact with the operating system 


and therefore has intimate knowledge of code, data 
structures and system objects. 


2) Since the 
debugger 
is just 
another 
task 
in the 
system, it does not affect the operation of the other 
tasks that are running. 


, 
3) Through 
the 
use of sophisticated 
breakpointing 


facilities, the debugger allows the designer to track 
the tasks in the system, investigate 
their interac- 


tion with other tasks and selectively 
stop one or 


more tasks without stopping the entire system. 


MUltiprogramming 


In some application systems, there arises the require- 
ment to run several "applications" on the computer at 
the same time. This may be due to the desire to 
squeeze more use out of the hardware or it may be due 
to some system design consideration. 
These separate 
"applications" (often termed jobs) share many system 
resources (especially the CPU) but at the same time 
they need to be protected 
as much as possible from 


other jobs. In essence, it should be possible to develop 
two jobs independently 
and then run them both on the 


same hardware without any interaction. 
If interaction 


is desired, the operating system should support some 
well-defined protocol for jobs to use to communicate. 


Free Space Management 


One of the most important 
resources in the computer 


system 
is the 
memory. 
In some applications, 
.the 


amount of memory needed can be determined 
when 


the system is designed. In the more general case, the 
amount of memory needed by the system fluctuates. 
One solution to this management 
problem is to have 


available 
the amount 
needed in the worst possible 


case. A more flexible and economical solution is to 
dynamically allocate memory from a central pool upon 
demand 
and return 
it when possible. This service 


provides two tangible advantllges. First, total memory 
needs are reduced. Second, this service allows for ease 
of use by the application programmer 
because there is 


no need to set aside blocks of memory and implement 
code to maintain information about current usage. 


File Management 


The ability to easily store and retrieve data stored on 
mass storage devices is a requirement 
in many appli- 
cation systems. Devices such as disks, tapes and bubble 
memories are used to store program code, data files 
and parameter 
tables. The operating system is called 


upon to store and retrieve 
the data and organize it 


such that 
application 
programs 
can easily find and 


manipulate the data when necessary. 


Typically, this service is provided through the use of a 
file system. The mass storage device is partitioned 
into 


blocks and logical addresses are assigned to the blocks. 
Files are created 
to serve as directories 
where the 


names of other files can be cataloged and looked up. 


In many systems, the directory structure can go many 
levels deep (see Figure 1). This provides several advan- 
tages. Directory searches can be done much faster if 
the general area where a file exists is known. Also, if 
several jobs are running at the same time, each can be 
given its own directory and therefore isolated from the 
others. Lastly, for human users, it is much easier to 
manage the information on the disk when some logical 
structure of files exists. 


Device Independence 


One of the unfortunate 
characteristics 
of 110devices is 


that they all tend to present different interfaces to the 
system software. When this is the case, the application 
programmer 
must become familiar 
with the unique 


characteristics 
of each device in order to communicate 
with it. One solution is to create an 110 driver which 
does the actual 110. This driver can then be called by 
the 
application 
program 
whenever 
communication 


with the device is desired. 


The problem with this solution is that the programmer 
must still know what type of device is being talked to 
since the 110 driver is specialized. If the system con- 
figuration 
changes, 
all 
of the 
software 
must 
be 
rewritten 
to call new device drivers. The best solution 
is to design a standard interface to device drivers and 
postpone 
until 
run-time 
the 
decision 
about 
which 
devices to use. With this type of system, an application 
program can be written assuming that at run-time the 
human or program that invokes it will provide a speci- 
fication of which devices should be used. 


High·Level Man·Machine Interface 


In addition 
to the services provided for application 
programs 
by the operating 
system, a set of services 


typically is offered to the human user sitting at the 
system console. System 
utilities 
are needed for file 


copying, disk formatting, 
and directory maintenance. 


Programs 
need to be loaded off disk to run and the 
programs 
themselves 
must 
be 
able 
to 
retrieve 
parameters 
passed to them by the operator. 
All of 
these 
functions 
are usually 
provided 
by the 
man- 
machine interface software in the operating system. 


Make Versus Buy 


The previous sections dealt with operating system re- 
quirements. 
These requirements 
are encountered 
in 
the application 
development 
process. 
Whether 
the 


solution to meet the needs comes from the individual 
application 
designer 
or 
from 
a computer 
system 
vendor, the requirements 
do not change. 


There usually exists a rather simple tradeoff between 
designing 
a custom 
operating 
system 
or buying 
a 
generalized system and tailoring 
it to the individual 
needs of the application. There are advantages 
to the 
custom 
solution. 
The 
system 
can 
often 
be made 
smaller since the requirements 
are known in great 
detail. Also, some small performance 
improvements 


can sometimes be made by taking advantage 
of the 


special cases to speed things up. 


Buying an operating system from a computer system 
vendor offers five advantages. 


1) Engineering resources are becoming scarce. The use 


of an opearting system from a vendor allows atten- 
tion to be focused on the application software. 


2) The time taken to bring the product to market can 


be shortened, 
thereby 
gaining a competitive edge 


and generating early revenue. 


3) Long-term 
maintenance 
costs can be reduced be- 


cause the vendor 
supports 
the operating 
system 


software. 
4) Personnel in all branches of the Gompany can be- 


come familiar with one software architecture 
and 


apply 
this 
knowledge 
to 
a range 
of products. 


This applies not only to the design engineers, 
but 


also to quality assurance, 
customer engineers and 
system analysts. 


5) The computer 
system 
vendor 
has knowledge 
of 


future technological advances coming in the prod- 
uct lines. For this reason, the operating system can 
be constructed so that applications software can be 
transported 
to future 
hardware 
without 
the need 


for expensive redesign. 


In summary, 
the trade-offs 
are clear. An operating 


system from a computer 
system 
vendor is not the 


answer for every application. 
But in most cases, the 


most economical and safest bet is to take advantage of 
the expertise of the vendor for the system software 
and use engineering 
resources to more quickly solve 


the application problem. 
. 


INTRODUCTION 
TO THE iRMX 86™ 


OPERATING SYSTEM 


The iRMX 86 Operating 
System meets the needs of 


real-time applications while simultaneously 
providing 


the full set of services normally found in a general- 
purpose operating system. 


The overall picture of the iRMX 86 Operating System 
is shown in Figure 2. The iRMX 86 Nucleus provides 


support 
for multitasking, 
multiprogramming, 
inter- 


task 
communication, 
interrupt 
handling 
and error 


checking. The Basic I/O System provides support for 
device 
independent 
and 
file 
format 
independent 


manipulation 
of data on 1/0 devices. The Extended I/O 


system 
provides 
synchronous 
I/O calls, 
automatic 
buffering, logical file name support and high-level job 
management. 
The 
application 
loader 
provides 
the 


ability to load code and data from mass storage devices 
into RAM memory. The Human Interface provides for 
a high-level 
man-machine 
interface 
as well as file 
utilities and parsing support for application programs. 


The following sections deal in more detail with each of 
these iRMX 86 pieces. If more information is desired on 
the features discussed, please refer to the documents 
listed in the front of this application note. 


Architecture 


The iRMX 86 architecture 
is an object-oriented archi- 


tecture. 
This means 
that 
the 
operating 
system 
is 


organized as a collection of building blocks that are 
manipulated 
by operators. The building blocks of the 
iRMX 86 system are called objects and are of several 
types. Some of the object types are tasks, jobs, mail- 
boxes, semaphores 
and segments. 
These types 
are 


explained in subsequent 
sections of this application 


note. 


This type of architecture 
has two major advantages. 
First, the system is easier to learn and use. The at- 
tributes of the various objects and the operations that 
can be performed 
on them are well defined and con- 


sistent. Once an object type is understood, 
all objects 


of that type are understood. 


The second advantage 
to an object-oriented 
archi- 
tecture is the ease with which the operating 
system 


can be tailored to the application. If there is no need 
for a given object in the application, all operators for 
that object are not included in the final configured 
system. On the other hand, if the application designer 
needs a more complex building block that is not in the 
basic system, he can define and use a new object type. 


Table 1 lists all of the system calls in the iRMX 86 
Nucleus. There are three groupings of system calls in 
this table. 


1) The general system calls apply to all objects uni- 


formly. 


2) The first two system calls for each object are the 


create and delete calls. These calls simply create a 
new object and initialize its attributes 
or delete an 


existing object. 


3) The remaining 
system calls are specific to the at- 


tributes of a particular 
obj~ct. With this organiza- 


tion in mind, the entire operation of the iRMX 86 
nucleus can be glimpsed in a single table. 


Tasks 


Tasks are the active objects in the iRMX 86 archi- 
tecture. Tasks execute program code and therefore are 
the only objects that can manipulate other objects. The 
attributes 
of a task include its program counter, stack, 


priority and dispatcher state. 


Tasks compete with each other for CPU time and the 
iRMX 86 scheduler determines which task to run based 
upon priorities. The dispatcher 
states for an iRMX 86 


task are shown in Figure 3. At any given point in time, 
the highest 
priority 
task that 
is ready to run has 


control of the CPU. Control is transferred 
to another 


task only when 
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Figure 3. Task State Transition 
Diagram 


1) the running task makes a request that cannot im- 


mediately be filled and is, therefore, 
moved to the 


asleep state, 


2) an interrupt occurs causing a higher-priority 
task to 


become ready to run or 
3) the running 
task causes a higher-priority 
asleep 


task to become ready by releasing some resource. 


The 
suspended 
and 
asleep-suspended 
states 
are 


entered whenever the suspend system call is invoked 
for a particular task. 


Job and Free Space Management 


Support for multiprogramming 
is provided by the job 


object. A job provides the environment 
for tasks to 


execute their programs. All other objects needed for a 
particular 
application 
are contained 
within 
the job. 


System 
Calls for 
O.S. Objects 
Attributes 
Object·Specific 


All Objects 
System 
Calls 


JOBS 
Tasks 
CREATE$JOB 
Memory 
pool 
DELETE$JOB 


Object 
directory 
SET$POOL$MIN 
Exception 
handler 
GET$POOL$ATIRIB 
OFFSPRING 


TASKS 
Priority 
CREA TESTASK 


Stack 
DELETE$T ASK 


Code 
SUSPEND$TASK 


State 
RESUME$TASK 


Exception 
handler 
GET$EXCEPTION$HANDLER 
SE T$EXCEPTION$HANDLER 


CATALOG$OBJECT 
. SLEEP 


GET$TASK$TOKENS 


UNCATALOG$OBJECT 
GETSPRIORITY 
SET$PRIORITY 
-- 
LOOKUP$OBJECT 
SEGMENTS 
Buffer with length 
CREATE$SEGMENT 
DELETE$SEGMENT 


ENABLE$DELETION 
GET$SIZE 


MAILBOXES 
List of objects 
CREATE$MAILBOX 
DISABLE$DELETION 
List of tasks 
wait.ing for objects 
DELETE$MAILBOX 
SEND$MESSAGE 
FORCE$DELETE 
RECEIVE$MESSAGE 


GET$TYPE 
SEMAPHORES 
Semaphore 
unit value 
CREATE$SEMAPHORE 


List of tasks 
waiting 
for units 
DELETE$SEMAPHORE 
RECEIVE$UNITS 
SEND$UNITS 


REGIONS 
List of tasks 
waiting 
for critical 
CREATE$REGION 


section 
DELETE$REGION 
RECEIVE$CONTROL 
ACCEPT$CONTROL 
SEND$CONTROL 


USER 
License 
rights 
to a given extension 
CREATE$EXTENSION 


OBJECTS 
type 
DELETE$EXTENSION 


New object 
template 
CREATE$COMPOSITE 
DELETE$COMPOSITE 
INSPECTSCOMPOSITE 
ALTER$COMPOSITE 


A specific 
attribute 
of the job is a free 
memory 
pool 
from 
which 
blocks 
can 
be 
allocated 
only 
by 
tasks 
within 
the job. Also, 
the job contains 
an object 
direc- 
tory 
which 
can 
be used 
by tasks 
to catalog 
objects 
under 
ASCII 
names 
so that 
other 
tasks, 
knowing 
the 
ASCII 
name, 
can look up the object 
and thereby 
gain 
addressability 
to it. 


More than 
one job can co-exist 
in the computer 
system. 


Tasks 
within 
jobs can also create 
children 
jobs forming 


a hierarchical 
tree 
of jobs 
(see Figure 
4). Each 
job in 
the system 
has its unique 
set of contained 
objects, 
its 


own memory 
pool and its own object directory. 


Segments 


A fundamental 
resource 
that 
tasks 
need 
IS memory. 


Memory 
is 
allocated 
to 
tasks 
in 
the 
form 
of 
the 


segment 
object. 
The segment 
is a block of contiguous 


memory. 
The 
attributes 
of 
a segment 
are 
its 
base 


address 
and 
size. A task 
needing 
memory 
requests 
a 


segment 
of whatever 
size 
it 
reqUITes 
The 
Nucleus 


attempts 
to create 
a segment 
from 
the 
memory 
pool 


given to the task's 
job when the Job was created. 


If there is not enough memory available, the Nucleus 
will try to get the needed memory from ancestors of 
the job. 


Communication and Synchronization 


In many cases it is necessary for two tasks to com- 
municate 
in order to exchange data and commands. 
This is supported through the use of an object known 
as a mailbox. As its name implies, a mailbox is a 
holding place for objects. One task can send an object 
to a mailbox, causing the object to be queued there. 
Another task can later receive an object from the mail- 
box and thereby gain access to it (see Figure 5). If a 
task tries to receive an object from a mailbox and there 
are no objects there, the task can optionally be made to 
sleep for a specified time for an object to appear. 


Note that any object can be sent to a mailbox to be 
received by another task. Typically, the object sent is a 
segment which is a block of memory and can contain 
any commands or data. The term message is often used 
to describe the object during the time it is being sent 
through a mailbox. 


In those cases where there is a requirement 
for syn- 


chronization between tasks but no data need be sent, a 
simpler 
more efficient 
mechanism 
exists. The sem- 
aphore object provides for the allocation of abstract 
entities 
called units. 
The primary 
attribute 
of the 


semaphore is an integer number. Tasks may send units 
to a semaphore thereby increasing the integer number 
or they can request 
units, 
thereby 
decreasing 
the 


number. If a task makes a request for more units than 
are available, it can optionally be made to sleep for a 
specified amount of time. This mechanism can be used 
for synchronization, 
resource allocation and mutual 


exclusion. 


Interrupt Management 


When an interrupt 
is sensed by the 8086 hardware, a 


user 
interrupt 
handler 
is executed. 
The interrupt 


handler 
can either 
perform 
all interrupt 
processing 
itself without making any iRMX 86 system calls, or it 
can signal an interrupt 
task allowing more general 


interrupt 
processing including calls to the operating 


system. 


The operating system maps hardware interrupt 
priori- 


ties into the software 
priority 
scheme allowing the 


designer to specify what software 
functions 
are im- 


portant enough to have some interrupt 
levels masked 


off during 
their 
execution. 
Although 
this mapping 


should always be kept in mind during 
design, 
the 


mechanics 
of dealing 
with 
interrupt 
control 
are 


handled by the operating system. 


Error Management 


One of the central themes in the design of the iRMX 
86 operating system has been reliability. The results of 
these efforts are evident in two particular 
features of 


the architecture. 
Beyond the ease of understanding 


brought 
about by the symmetry 
of the system, 
the 


reliability of applications using the iRMX 86 software 
is increased. 


The general case (as opposed to checking only for 
specific combinations of errors) has been designed for. 
Because of this, an unexpected combination of events 
or the 
simultaneous 
occurrence 
of interrupts 
will 


never catch the system by surprise. 


In the event that errors do occur, the operating system 
is set to detect them. Virtually all parameters 
in calls 


to the operating system are checked for validity. Any 
inconsistency 
causes a jump to an error 
routine 
to 


handle the problem. Two types of errors can poten- 
tially occur and there are two ways of handling errors. 


The first error type is the programmer error condition 
which comes about due to some mistake in the coding 
of a system call. The second type is an environmental 
condition which arises due to factors out of the control 
of the engineer 
(e.g. insufficient 
memory). Each of 


these error types can be handled in-line by checking a 
status code upon return from the call or can cause an 
error handling subroutine to be called by the system. 
The system designer can choose the desired method for 
the system, for a specific job, and even for individual 
tasks within a job. 


Asynchronous I/O 


Asynchronous 
I/O 
system 
calls 
are 
provided 
to 


support device independent 
1/0 to any device in the 


system. The type of 110 and the type of device are 
interrelated 
as shown in Figure 6. Every device driver 
in the 110 system is required 
to support a standard 
interface. In this manner, all devices look the same to 
higher 
level 
software. 
In 
the 
same 
manner, 
the 
individual 
file drivers, 
which provide the different 
types of file systems, all have a standard interface and 
call upon the various device drivers to perform 110. 
These interface standards 


1) provide for the device independence 
in the higher 
layers of the 110system 
2) make it easier for Intel to add future device drivers 
as new devices become available and 
3) make it possible for iRMX 86 users to add their own 
drivers for custom 110devices. 


The iRMX 86 110 system provides both asynchronous 
and synchronous 
system calls. The asynchronous 
110 
calls 
are 
faster, 
provide 
more 
flexibility 
in 
the 
selection of options and allow the program making the 
call to perform other functions while waiting for the 
110operation to complete. 


The method by which the 110 system responds to the 
requestor is through the use of a mailbox. When any 
call is made to the asynchronous 110system, one of the 
parameters 
indicates 
a mailbox 
where 
the 
caller 


expects to receive a segment containing the results of 
the operation (see Figure 7). 


Synchronous 
110 
The alternative 
to using the asynchronous 110 system 


is to use synchronous 
110 system calls. As shown in 
Figure 8, the number of options available are fewer 
and the caller cannot 
continue 
execution 
until 
the 
entire 110operation is completed but from an ease-of- 
use standpoint, the situation is much simplified. 


Response$mailbox$token 
= RQ$create$ 


mailbox (0, @status); 
CALL RQ$A$read(connection$token, 
buf$ptr, 


count, response$mailbox$token, 
@status); 


10RS$token = RQ$receive$message 
(response$mai Ibox$token, 0 FFFFH, 
@resp$t, @status); 


{check status\ 
Call RQ$delete$segment(IORS$token, 


@status); 


Call RQ$S$read(connection$token,buf$ptr, 


count, @status); 
{check status\ 


Figure 8. Synchronous 
1/0 Call 


Two other 
features 
provided 
by the Extended 
110 


System are logical name support 
and autobuffering. 


Logical names allow the application designer to post- 
pone the decision concerning which files to use until 
run-time. Essentially, all programs can be written and 
compiled 
using 
logical file names 
and 
then 
these 


logical names can be mapped into real file names at 
run-time. 


The use of autobuffering 
regains much of performance 


advantage offered by overlapped 1/0. When a user task 
opens a file for input, one or more buffers are auto- 
matically created and filled with data from the file. 
Thus, when the user task makes an 110 request, 
the 


data may already be available in memory. A similar 
case exists for write requests in that the 1/0 system 
will buffer data to be written to a device, allowing the 
user task to continue on. 


Loaders 


The iRMX 86 application loader and bootstrap 
loader 


perform a variety of services for the user software. 
The following is a brief summary 
of the available 


features. 


1) Systems 
can be boot loaded from mass storage 


devices at system reset. This saves not only ROM or 
EPROM memory, 
but also reduces 
field mainte- 


nance costs by allowing easy field updates. 


2) Users can design their 
own SYSGEN procedure 


allowing tailoring of an application 
system to the 


individual installation. 


3) Infrequently 
used programs can be brought in from 


mass storage when needed instead of using system 
memory unnecessarily. 


File Management 


There are three types of files supported by the iRMX 
86 110 system, named files, physical files and stream 
files. Named files are supported on devices possessing 
mass storage 
capability. 
Files in this 
system 
have 


ASCII pathnames 
and are catalo'ged in directories. 
Each device in the system contains a directory tree as 
shown previously 
in Figure 
1. Access protection 
is 


'provided through the use of access lists for each file. 
Each user or group of users in the system can be given 
different 
types of access to the file or can be denied 


access to it. 


For devices that cannot support a named file structure 
(e.g. printers and terminals) the physical file driver is 
used. Devices in this category are treated 
strictly as 
data 
going into and/or 
out of the device. If it is 
desirable to treat a mass storage device strictly as a 
large mass of data, it can also be addressed through 
the physical file driver. 


The third type of file is the stream file. This file type 
has no correlation with any physical device but rather 
uses system memory for temporary storage of data. An 
example of the usage of a stream file is a job that gets 
its input stream 
of data from a file. Depending 
on 


which time the job is run, this file might be a named 
file on disk, a terminal, or a stream file being written 
to by another job (see Figure 9). 


RUN 
1 


~ 
INPUT 
~ 
OUTPUT 
~ 
~~ 


'RUN 
2 
~ 
INPUT 
~ 
OUTPUT 
~ 
L-J-~ 


TERMINAL 
. 


Human Interface Subsystem 


The highest level of support provided by the iRMX 86 
Operating System is the Human Interface Subsystem. 
This piece of software 
provides two basic services. 


Programs can be invoked by typing the program name 
at the system console. The Human Interface will load 
the given program into memory, set it up as a job and 
start it running. 
The invoked program can then call 


upon the Human Interface routines to determine what 
parameters 
were passed to it as part of the operator 


input. 


The Human Interface 
also contains 
a set of system 
utility routines which are used to copy files and disks, 
format disks, dynamically alter the system configura- 
tion and others. 


Debugging Subsystem 


The iRMX 86 Debugging 
Subsystem 
allows the de- 


signer to interact with the prototype system and iso- 
late and correct program errors. Since the debugger is 
an object-oriented 
debugger and is aware of the in- 


ternal structure of the operating system, it can provide 
detailed information 
concerning objects and can mon- 
itor mailboxes and semaphores providing a breakpoint 
facility as well as error detection. 


Specifically, 
the 
iRMX 
86 
Debugging 
Subsystem 
provides six sets of functions: 


1) Wake-up upon operator 
invocation. 
The operator 
types a control-D 
key to cause the debugger 
to 
wakeup. 
' 


2) View system lists. The debugger can view lists of 


objects either 
globally or specifically for a given 


job. Also, lists of objects and tasks queued at mail- 
boxes and semaphores can be seen. 
3) Inspect objects. A detailed report on any object can 
be requested 
showing 
the 
current 
state 
of all 
relevant attributes. 
4) Inspect and modify memory. 
5) Breakpoint 
control. 
Any number 
of breakpoints 


can be set causing a single task to break on either 
execution of particular 
instructions 
or sends and 


receives of messages or units. 


6) Error handling. The debugger can be set up to be 


the system 
default 
error 
handler 
thus 
catching 


system exceptions. 


Configuration and Initialization 


Once the 
application 
is designed 
and 
coded, 
the 


engineer needs a mechanism to inform the operating 
system of the software 
and hardware 
configuration. 


Essentially, 
this involves building tables of informa- 


tion using tools provided with the iRMX 86 product. 


As shown earlier in Figure 4, the jobs in an iRMX 86 
system form a hierarchical tree. The root in every job 
tree is known as the root job and is supplied as part of 
the iRMX 86 system. There are three important 
fea- 
tures of this job. 


1) The root job has an object directory for cataloging 


and looking up objects. The special feature of this 
directory is that is is accessible by all tasks in the 
system since everyone can address the root job. For 
this reason the root object directory 
is useful for 


setting up inter-job communication paths. 


2) The root job initially contains all free space in the 


system. Part of the system initialization 
code per- 


forms a memory scan to automatically 
determine 


the 
amount 
of free 
RAM in the 
system. 
This 


memory is put into the free space pool of the root 
job and parceled out as user jobs are created. 
3) The root job contains only one task, the root task. 


This task scans the configuration 
tables generated 


by the user and creates the user-specified jobs. 


Examples 
of configuration, 
initialization 
and 
the 
LINK 86 and LaC 86 operatio~s needed to generate a 
system will be presented in the Code Examples section. 


This section describes the design process involved in 
using the iRMX 86 system to solve application prob- 
lems and presents two example solutions. 


System design with the iRMX 86 OIJerating System 
should be viewed as a process starting with tne highest 
level definition 
of system requirements 
and succes- 
sively .adding more detail 
until 
the end product 
is 
program code. This description sounds very much like 
the description 
of top-down design and, of course, it 


should. 
This 
methodology 
offers 
not only quicker 
designs, fewer design flaws and easier implementation, 
but also easier maintenance and enhancement. 


In general, every iRMX 86 design progresses through 
the following steps: 


1) Define system requirements. 
2) Breakdown into highest level sub-functions Gobs). 
3) Define job functions. 
4) Determine inter-job command and data flow. 
5) Break down each job into sub-functions. 
6) Based upon requirements, 
assign tasks to perform 
job functions. 


7) Determine inter-task command and data flow. 
8) Write program code for each task. 


Step 8 becomes the design process associated with the 
application 
programs 
themselves. 
The code for each 
task is essentially a sequential program that performs 
one of the functions of the computer system. Standard 
techniques for top-down design can therefore be used 
here to specify each module and its inputs and outputs 
as well as global and local data structures etc. The end 
product of this procedure is a modularized application 
system that should be easy to debug. 


APPLICATION 
EXAMPLE 1 


The first example presented 
here is based on the dis- 
tributed local network diagrammed in Figure 10. Each 


workstation 
shown is an intelligent 
termmal 
having 


local data and program 
storage. The stations 
all use 


the File Sharing Node (FSN) for storage and retrieval 
of records in much the same way as the secretaries in 
an office would make use of a filing cabinet. The FSN 
maintains the files on a fixed disk device and responds 
to requests 
from the workstations 
for access to the 


data. The design to follow concentrates 
on the File 


Sharing Node. 


System Requirements 
Each intelligent terminal in the network has command 
processing software. 
When a file reference 
is made 


that 
cannot be satisfied 
by the local file system, 
a 


request is made to the File Sharing Node. This request 
consists of a log-on request followed by a string of IJO 
requests and ultimately a log-off request. 


The number 
of intelligent 
terminals 
(workstations) 


hooked up to the FSN varies 
from installation 
to 


installation. 
Therefore, 
the FSN must be capable of 


handling many simultaneous requests and no assump- 
tions can be made about the maximum 
number 
of 


workstations or requests that may need to be handled. 


Each node in the network 
has a unique address. 
A 


packet is sent onto the network by one node and the 
address field is examined by all other nodes. If this 
field does not match the node's address the packet is 
ignored. If a match is found the packet is retrieved 
from the network. 


Hardware Requirements 


The three main hardware 
building blocks needed by 


this application 
are shown in Figure 
11. The iSBC 


86/12A 
Single 
Board 
Computer 
will communicate 


with the iSBC 544 Intelligent 
Communications 
Con- 


troller to establish and maintain communications with 
the network. The Intel 8085A on the iSBC 544 board 
will perform all of the address recognition, 
acknowl-. 


edgements, 
packet retrieval 
and packet transmittal. 


The iSBC 206 Hard Disk Controller 
will be used to 


create, maintain and access the data files which are at 
the heart of this applicatio~. 


System Design 
The first step in the system design process is the 
breakdown of the system functions into one or several 
jobs. The reasons for doing this are system modularity 
and protection. With this type of design, each job can 
be designed separately, perhaps even by a different 
engineer or engineering team. The input and output 
requirements will be specified very tightly and the job 
will take on the appearance of a black box to other jobs 
in the system. If the job is enhanced or modified at a 
later date, the rest of the system can be left undis- 
turbed providing that the input and output response 
remains the same. 


The job object in the iRMX 86 operating system also 
affords a degree of software protection for the tasks 
and other objects contained within the job. Each job 
has 
a separate 
memory 
pool, a 
separate 
object 
directory and a separate 
identification 
to the I/O 
system. 


The two primary groupings of functions in this appli- 
cation are those related to the network communica- 
tions and those related to processing the file trans- 
action request. A list of a possible split-up of system 
functions is shown in Figure 12. 


COMMUNICATIONS 
JOB 
FilE 
TRANSACTION 
JOB 


• iSBC 544'" 
INPUT 
INTERRUPT 
• RETRIEVE 
INPUT 
REQUEST 


SERVICE 
PACKETS 
FOR SERVICING 


• iSBC 544'· 
OUTPUT 
INTERRUPT 
• DETERMINE 
WORKSTATION 


SERVICE 
STATUS 


• SERVICE 
OUTPUT 
REQUEST 
• SERVICE 
TRANSACTION 
MAilBOX 
REQUESTS 


• QUEUE 
PACKETS 
OF INPUT 
DATA' 
PERFORM 
LOG·ON 
AND 
LOG·OFF 


AT INPUT 
MAILBOX 
FUNCTIONS 


The communication between the file transaction job 
and the communication job must fulfill two basic 
needs. The communication job will receive interrupts 
when packets addressed to the FSN are received. 
In order to remain attentive to new requests coming 
in, the communications job should have the capability 
to "spool" the requests off to the file transaction job. 
This buffering can be provided by using the mailbox 
object. Segments can be created to contain the packet 
request data and can then be sent to a mailbox where 
the file transaction job can receive and process them. 


When the file transaction job must send a packet to a 
workstation, 
the requirtlment 
is seen for another 
queue of requests. Since the communications board 
can only put one packet at a time on the network, a 
mailbox should be provided to allow tasks in the file 
transaction job to send output request segments into 
the queue and then continue on (seeFigure 13). 
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Since tasks in both the file transaction job and the 
communications job must have access to these input 
and output mailboxes, some means must be set·up to 
"broadcast" the identifier for these objects. 


In the iRMX 86 system, each object has associated 
with it a 16-bit number called a token. Whenever an 
object is referenced in an operating system call, the 


token for the object is used. For example, assume that 
a segment must be sent to a mailbox. The segment and 
mailbox each have a token and these tokens are passed 
to 
the 
operating 
system 
as 
parameters 
in 
the 
send$message system call. 


There are three major ways to get the token for an 
object. The first way is to create an object. Whenever 
the operating system is called to create a new object, 
the value returned from the procedure call is the token 
for the new object. The second way to receive a token 
is through the receive message system call where an 
object is received from the queue at a mailbox where it 
was sent by another task. 


The third major mechanism for the receipt of a token 
is provided by the object directory concept. As men- 
tioned previously, each job in the system has an object 
directory. 


If a task in a job has the token for an object and wishes 
to let other tasks in other jobs have access to the 
object, the task can "catalog" the object in the object 
directory. 
The catalog$objed 
system call takes the 
token for an object and an ASCII name as parameters 
and creates an entry in the object directory. If another 
task knows the ASCII name for an object, it can obtain 
the token by performing a lookup$object call. 


The object directory 
mechanism 
will be used in this 
example to allow the communications 
job to "broad- 
cast" the tokens for the input and output mailboxes. 
The jobs for this application are shown in Figure 14. 


The next step of the design methodology calls for each 
job to be further 
divided into sub-functions. 
In this 
application 
note, 
only 
the 
file 
transaction 
job is 
studied. 


1) Retrieve input requests from the mailbox set up by 


the communication job. 


2) Determine 
state 
of specified workstation 
(for ex- 


ample, is it logged on?). 


3) Perform I/O operation or log-on or log-off. 
4) Build and send response to the workstation. 


Recall from the discussion 
of system 
requirements 


that the number of nearly simultaneous 
requests that 


may be received by the FSN is not known. For this 
reason, some mechanism 
must be provided to allow 


parallel 
processing 
of many 
requests. 
This 
should 


prove feasible since the performance 
of step 3 will 


involve many delays while waiting for the operating 
system to perform I/O operations. 


One 
straightforward 
way 
to 
provide 
for 
parallel 


processing is to create a task for each workstation that 
logs on. In this manner, 
each I/O request 
will be 


handled 
by a unique task. Through 
the use of the 


iRMX 86 scheduler, maximum CPU utilization will be 
gained by allowing each task to individually compete 
for CPU time. These "worker" tasks fulfill function 3 
and 4 for the file transactionjob. 


Function 1 and 2 can be fulfilled by a single task. This 
task will wait at the input 
mailbox set up by the 


communications 
job. When a packet is received that 


requests 
a log-on operation, 
the "listener" 
task will 
create 
a new "worker" task to handle 
the request. 


Figure 15 shows a picture of the design. 


Figure 15. Diagram of Design of 


File Transaction 
Job 


The string 
of transaction 
requests 
that 
follow will 


simply be demultiplexed 
by the listener 
task. 
The 


workstation ID will be searched for and, if found, the 
packet will be sent to the appropriate 
worker task. If a 


request comes in from a station that is not logged on, 
an error response is sent directly to the communica- 
tions output 
mailbox for transmittal 
to the station 


that made the request. 


If the request packet indicates that a station desires to 
log-off, the listener task will delete all local reference 
to the station and pass the packet along. The listener 
task cannot simply delete the worker since the worker 
may be in the process of servicing 
a previous 
I/O 
request. 
In general, it is never a good idea to arbi- 
trarily delete another task. A better protocol is to pass 
along the message signaling the worker task to delete 
itself when convenient. 


An investigation 
of the 
intertask 
communications 
needs highlights 
the requirement 
for passing 
data 
between tasks. The interjob communications 
protocol 
discussed earlier specified that the listener task will 
receive input request segments from the communica- 
tions job via a mailbox. 


Within these segments are fields containing the work- 
station ID and the command. Based upon these fields 
one of two things happens. If the command indicates 
that the station wishes to log on, a new worker task 
must be created to process the I/O requests that will 
follow. 


The code executed by all worker tasks will be identical 
since they all perform identical 
functions. However, 


some unique pieces of information must be passed to a 
new worker task. This can be accomplished by having 
the worker task first wait at a "log on" mailbox. Here it 
will receive a segment from the listener 
task which 


contains the necessary information (see Figure 16). 


Figure 16. Communications 
Between 
Listener 
Task and a Newly Created 
Worker Task 


After this initialization 
is complete, the workstation 


requests that are received by the listener task can be 
sent to the service mailbox associated with the work- 
station. The token for the service mailbox is one of the 
pieces of information contained in the log on segment. 


The last communication 
path needed is predefined by 


the interjob communication protocol. When either the 


listener 
task or one of the worker 
tasks 
needs 
to 


transmit 
a packet to a workstation, 
a segment is sent 
to the output request mailbox of the communication 
job. 


The final step in the design methodology is to write 
program code for the tasks in the system. This step is 
performed in the Code Examples section. 


This example will deal with the design of a custom 
device driver for the iRMX 86 operating 
system. As 


shown in Figure 6, a device driver accepts high-level 
commands from the file drivers (such as read, write, 
seek, etc.) and transforms 
these commands 
into I/O 
port read and write commands 
in order to commu- 
nicate with the device itself. By studying the construc- 
tion of a driver for the iSBC 534 Serial Communication 
Expansion Board, a better understanding 
of the iRMX 


86 I/O system will be gained along with an example of 
the use of nucleus facilities to construct a higher-level 
software function. 


Overview of Device Driver Construction 


Each I/O device consists of a controller 
and one or 


more units. 
A device as a whole is identified 
by a 


device number. Units are identified 
by unit number 
and device-unit number. 
The unit number identifies 


the unit within the device and the device-unit number 
identifies 
the unit among all the units on all of the 


devices. 


A device driver must be provided for every device in 
the hardware configuration. 
That device driver must 


handle the I/O requests 
for all of the units on the 


device. Different 
devices 
can .use different 
device 


drivers; or if they are the same kind of device, they can 
use the same device driver code. 


At its highest level, a device driver consists of four 
procedures 
which 
are 
called 
directly 
by 
the 
I/O 
System. These procedures can be identified according 
to purpose, as follows: 
. 


Initialize I/O 
Finish I/O 
Queue 1/0 
Cancel 1/0 


When a user makes an I/O System call to manipulate a 
device, the I/O System ultimately 
calls one or more of 


these procedures, which operate in conjunction 
with 
an interrupt 
handler 
to coordinate 
the actual 
I/O 
transfers. 
This section provides a general description 
of each of these procedures, and the interrupt handler. 


INITIALIZE 
1/0 


This procedure 
creates 
all of the iRMX 86 objects 
needed by the remainder of the routines in the device 
driver. It typically creates an interrupt 
task and a seg- 
ment to store data local to the device. It also performs 
device initialization, 
if any such is necessary. The I/O 
System calls this routine just prior to the first attach 
of a unit on the device (the first RQ$A$PHYSICAL 
$ATTACH$DEVICE system call). The time sequence 
of calls to these procedures 
will be described a little 
later. 


FINISH 
1/0 


The I/O System calls this procedure after all units of 
the 
device 
have 
been 
detached 
(the 
last 
RQ$A$ 
PHYSICAL$DETACH$DEVICE 
system 
call). 
The 
finish$IO 
procedure 
performs 
any 
necessary 
final 
processing on the device and deletes all of the objects 
used by the device handler, 
including 
the interrupt 
task and the device-local data segment. 


QUEUE 
1/0 


This procedure places I/O requests on a queue, so that 
they can start 
when the appropriate 
unit becomes 
available. 
If the device is not busy, the queue$IO 
procedure starts the request. 


CANCEL 
1/0 


This 
procedure 
cancels 
a 
previously 
queued 
I/O 
request. Unless the device is such that a request can 
take an indefinite amount of time to process (such as 
keyboard input from a terminal), 
this procedure can 
perform a null operation. 


INTERRUPT 
HANDLERS 
AND INTERRUPT 
TASKS 


After a device finishes processing an 110 request, 
it 
sends an interrupt 
to the iRMX 86 system. 
As a 
consequence, the interrupt 
handler 
for the device is 
called. This handler 
either 
processes 
the interrupt 
itself 
or signals 
an interrupt 
task 
to process 
the 
interrupt. 
Since an interrupt 
handler is limited in the 
types of system calls that it can make, an interrupt 
task usually services the interrupt. 
The interrupt 
task 
feeds the results of the interrupt 
back to the appli- 
cation software 
(data from a read operation, 
status 
from other types of operations). It then gets the next 
I/O request 
from 
the queue and starts 
the device 
processing this request. This cycle continues until the 
device is detached. 
The interrupt 
task is normally 


created by the initialize I/O procedure. 


The I/O System calls each one of the four device driver 
procedures in response to specific conditions. Three of 
the 
procedures 
are 
called 
under 
the 
following 


conditions. 


1) In order to start 110 processing, the user must make 


an I/O request. This can be done by making a variety 
of system calls. However, the first I/O request 
to 


each device-unit must be the RQ$A$PHYSICAL$ 
ATTACH$DEVICE system call. 


2) The I/O System 
checks to see if the I/O request 


results from the first RQ$A$PHYSICAL$ATTACH 
$DEVICE system call for the device (the first unit 
attached in a device). If it is, the I/O System realizes 
that the device has not been initialized and calls the 
initialize I/O procedure 
first, before queueing the 


request. 


3) Whether or not the I/O System called the initialize 


I/O procedure, it calls the queue 110 procedure 
to 


queue the request for execution. 


4) The I/O System checks to see if the request just 


queued resulted from the last RQ$A$PHYSICAL$ 
DETACH$DEVICE system call for the device (de- 
taching 
the last unit of a device). If so, the I/O 


System 
calls the finish I/O procedure 
to do any 


final processing on the device and clean up objects 
used by the device driver routines. 


The 
I/O 
System 
calls 
the 
fourth 
device 
driver 


procedure, 
the 
cancel 
I/O 
procedure, 
under 
the 


following conditions: 


• 
If 
the 
user 
makes 
an 
RQ$A$PHYSICAL$ 


DETACH$DEVICE system call specifying 
the 


hard detach option, in order to forcibly detach 
the connection objects associated with a device- 
unit. 


• 
If a job containing 
the task which made the 


request is deleted. 


Each procedure will now be discussed in more detail. 
The initialize $10 procedure takes three parameters: 


The duib$p parameter 
contains a pointer to a device 


unit information 
block (DurB) ~hich 
is the configu- 


ration table for the device in question. The structure of 
this table is shown in Figure 17. Note that this table 
contains pointers to device and unit information tables 
which can contain hardware specific information (such 
as I/O base addresses, interrupt 
levels etc.). 


The second parameter is a pointer to a word which can 
be assigned the value of a token for an iRMX 86 object. 
Quite often this object would be a segment which could 
be created 
by the init$io procedure 
and filled with 


information 
needed by the other procedures 
in the 


driver. The token for this segment will be provided to 
the other procedures when they are called. 


NAME 


(14) 


FILE 
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POINTER 
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INFORMATION 
POINTER 


The final argument 
in the call is a pointer to a status 
word. This word should be assigned by the init$io 
procedure before a RETURN is executed. If a non-zero 
value is returned indicating an error condition, the I/O 
System assumes that init$io has deleted any objects 
created before the error was encountered. 


The finish$io procedure is called by the I/O System just 
after the last detach$device call is made on the device. 
This 
procedure 
is expected 
to delete 
any 
objects 


created by the init$io procedure 
and shut down the 


connected device. 


Once again, the first parameter 
to the call is a pointer 


to a DUIB. The second parameter is the token returned 
by the init$io procedure. 


The queue$io procedure 
is called to initiate 
an I/O 


request. 


The specifics of the request 
are indicated 
in an I/O 


request segment (IORS) which is provided by the first 
parameter. 
The format 
of this segment is shown in 


Figure 
18. The most important 
fields here are the 
count, function, status and buffer pointer fields which 
tell the queue$io procedure what needs to be done. The 
second 
and 
third 
parameters 
are 
once again 
the 
pointer 
to the DUIB and the token for the object 


The final device driver procedure 
is cancel$io. This 


procedure 
is called by the I/O System 
to cancel a 


previous 110 request. If the device is of such a nature 
that a request will complete in a bounded amount of 
time, this procedure 
can be a null procedure. 
The 


parameters 
to the call are identical to those for the 


queue$io call. 


In addition to the elementary 
support discussed here, 


the 110 System provides extra support to the designer 
of a device driver 
if some simplifying 
assumptions 


about the device can be made. Also, if the device 
supports 
random 
access 
(such 
as disks, 
magnetic 


bubbles, etc.), support routines can be used to simplify 
the process of blocking and deblocking 110 requests. 
More detail on the process of writing 110 drivers can be 
found in the manual titled "A Guide to Writing Device 
Drivers for the iRMX 86 110System." 


Design of an iSBC 534™ Device Driver 


The following section will discuss an example device 
driver for the iRMX 86 Operating System. The driver 
will be for the iSBC 534 board which contains 
four 
8251 USART devices; therefore, 
there is one device 


and four units on the device. 


The init$io procedure 
for this driver initializes 
the 


hardware, 
creates 
an interrupt 
task, 
creates 
other 


necessary objects and creates a segment to contain the 
relevant information. 


The structure 
of the queue$io 
procedure is more 
complex. When calls are made to this procedure to per- 
form data reading and writing, the actual operation 
could be somewhat 
lengthy 
(especially an 
input 
operation). Since the queue$io procedure is called by 
the I/O system, it is not efficient to perform the entire 
operation before control is returned to the I/O system. 


A more efficient mechanism is to have an independent 
task take the request and fulfill it while the queue$io 
procedure returns to the I/O system allowing other 
operations to be started in parallel. This leads to the 
structure diagrammed in Figure 19. When a read or a 
write request is received, the I/O request segment is 
sent to the request mailbox where it is received by an 
I/O handler task. When the request is complete, the 
I/O task sends the segment to the response mailbox 
indicated in the segment. 


Figure 
19. Queue$io 
Procedure 
Interface 


to 110 Tasks 


The remaining design of the device driver is concerned 
with interrupt handling. The iSBC 534 board contains 
four 8251 USART devices. Each device supplies two 
interrupts; one indicating that the receiver has a data 
character available and the other indicating that the 
transmitter 
is ready to accept a character. Each of 
these interrupts (8 in all) are connected to one of the 
8259 Interrupt Controllers on the board. The software 
on the iSBC 86/12A board must read a register in the 
8259 controller to determine which of the eight sources 
caused the current interrupt. 
This information must 
then be fed to the 1/0 task which may be waiting for 
the event. 


One way to meet this requirement uses an interrupt 
task for the iSBC 534 board. The task receives the 
interrupt, 
determines 
which device caused it, and 
sends a unit to a semaphore to indicate the occurrence 
of the event. Thus, when an I/O task wishes to be 
informed of a receiver or transmitter 
interrupt, 
it 
simply tries to receive a unit from the appropriate 
semaphore. If a unit is available, the receiver has a 
character or the transmitter is ready. If the unit is not 


available, the USART is not ready and the task will be 
put in the asleep state until the interrupt occurs and 
the unit is sent. 


This chaper will present and analyze some sample code 
for the iRMX 86 applications presented in Chapter 4. 
The code listings are contained in Appendix A and the 
individual modules are numbered sequentially. When 
a specific line or sequence of lines of code must be 
pointed out in the text, a two part number is used 
where the first part is the module number and the 
second is the compiler-assigned 
line number. 
For 


example, 3.27 would be used to point out line 27 in 
module 3. 
. 


A standard set of suffixes to labels will be followed in 
the code to follow. A PLlM-86 WORD variable that 
will contain the token for an iRMX 86 object will have 
the suffix "$t." A POINTER variable will be followed 
by "$p" and a structure used to overlay a POINTER 
allowing access to the base and offset will be followed 
by "$p$o." 


The first module to be studied contains the code for 
the listener task. The various include statements bring 
in literal declarations and external procedure decla- 
rations. The file NUCPRM.EXT is on the iRMX 86 
diskette and contains the external declarations for all 
iRMX86 nucleus system calls. 


Line 1.323 contains all of the declarations for the 
module. The literal 
req$segment$struc 
is used to 


access the fields of a segment returned from the com- 
munications job. The format of a request packet from 
a workstation is shown in Figure 20. The literal node is 
used to access the information in a segment used as a 
workstation descriptor in a list maintained 
by the 


listener task. The format of a node in this list is shown 
in Figure 21. The structure at the end of the declara- 
tion statement is used to individually access the two 
halves of a 32-bit PLlM-86 POINTER. 


Note in line 1.330 that the task is coded as a public 
procedure having no parameters. 
A main procedure 


should never be used for a task's code since the pre- 
amble for a main procedure sets the stack pointer. 


The mailbox to be used for sending a newly created 
worker task an information 
segment is called the 


log$on$info$mbox. 
This mailbox is created in line 


1.331. Lines 1.332-1.334 perform the operation of 
finding the tokens for the communication job's input 
and output request mailboxes in the object directory of 
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the root job. The token for the root job is obtained by 
the system call in 1.332. 


Whenever a workstation 
logs on, various actions are 


taken 
by the 
listener 
task. 
One of these 
actions 
involves adding a descriptor 
for the workstation 
to a 
list so that the state of the workstation 
can be main- 
tained by the listener task. The list structure is shown 
in Figure 22. Statements 
1.336-1.340 create the root 


of this list and initialize the list to an empty state. 


Line 1.340 marks the beginning of an infinite 
loop. 
Most often a task executes a procedure which performs 
some initialization 
and then enters 
an endless loop 


performing 
the necessary processing. The literal "for- 
eper" translates into "while 1." 


A packet is received from the input mailbox by the call 
in line 1.341 
The command field of the message is 


checked in line 1.343. If the command indicates that a 
log on request 
is being made, lines 1.345-1.356 
are 
executed. A log on information 
segment 
IS created in 


line 1.345. A mailbox iJ, created 
to handle 
further 


request packets and another is created to be used by 
the worker task as a response mailbox. The worker 


task that 
will handle 
I/O requests 
from this work- 
station 
IS created in line 1.351. Note the use of the 
structure data$seg$p$o, which is declared at the same 
address as the POINTER data$seg$p. The POINTER is 
initialized to equal the beginning of the data segment 
of the worker task module (1.323) and then the base 
portion is used as a parameter in the create task call. 


Once the worker task is created, it will wait at the 
log$on$info$mbox 
for a segment giving it its initiali- 
zation information. 
The segment is sent in line 1.352 


and received back as an acknowledgement in line 1.353. 
At this point, the segment is inserted 
on the list of 


active workstation descriptors by the call in line 1.354. 
Finally the request packet itself is sent to the worker 
task via the service mailbox for the new worker. 


If a log off request is received, lines 1.358 to 1 366 are 
executed. First, the active workstation 
list is searched 


for the In of the requesting 
station. If the station is 


not found to be logged on, the status field is set and 
the request segment is sent to the workstation through 
the communications Job. If the station is logged on, the 
descriptor is deleted from the list, the packet is sent 
along to the worker task, and the descriptor is deleted. 


If the command 
IS anything but log on or log off lines 


1.368-1.376 are executed. Once again the statIOn ill is 
checked to see if it 
IS logged on. If not, an error 


message is returned. 
If the station 
is logged on, the 
request packet is sent along to the worker task. 


WORKER 
TASK 


The code for the worker task is shown in module 2. 
Upon creation 
of a new worker task, a segment 
is 
received at the log$on$info$mbox 
(2.242). The data in 


this segment 
is copied into local variables 
and the 
segment is returned (2.247). 


The initialization 
task for this job has already created 


a user object for this job and has also set up a prefix 
which points to the root directory for the disk device. 
These tokens have been cataloged in the root object 
directory. 
The 
worker 
task 
obtains 
these 
tokens 
through the sequence of calls 2.248-2.250. 


The worker task now enters an infinite loop servicing 
the workstation it is assigned to. The specific action to 
be taken by the worker is determined by inspecting the 
cmd field of the request message. 


If the command is a log on, the code from 2.256-2.263 
is executed. The file name specified in the request 
segment 
is attached 
and opened and thereby 
made 
ready for subsequent 
I/O requests. After this, an ac· 


knowledgement is sent back to the workstation via the 
output$request$mailbox 
(2.263). 


If a log off command is received, the file is closed and 
detached, 
the 
service 
and 
response 
mailboxes 
are 


deleted, a response is sent to the workstation 
and the 


worker task is deleted. 


If the command is either a read or write command, the 
operation 
is performed 
by calling 
the I/O system. 


When the response is received, an acknowledgement 
is 


sent to the workstation. 
Note that 
the task would 


normally perform more processing. In this example its 
duties have been kept simple. 


POINTERIZE 
PROCEDURE 


The ASM·86 code for the pointerize support routine is 
shown in Module 3. The token for a segment is the 
base portion of a 32-bit POINTER to the memory. In 
order to access the data in a segment, this 16-bit token 
must be loaded into the base part of a POINTER while 
the offset portion of the POINTER is set to zero. The 
base and offset values are returned 
in the ES and BX 


regusters 
as specified 
by the PLlM-86 calling con- 


ventions. 
This 
is the 
operation 
performed 
by the 
pointerize routine. 


LIST MANIPULATION 
ROUTINES 


Lines 4.1-4.47 provide three subroutines 
used by the 


tasks in this system to manipulate 
the list of work- 


station descriptors. 
Insert$on$list 
(4.15-4.26) inserts 


the indicated node at the head of the list whose root is 
given as the first parameter. 


Delete$from$list 
(4.27-4.35) 
unlinks 
the 
indicated 


node from the list it belongs to. Search$list (4.36-4.46) 
searches a list for the workstation ID given. If the ID is 
not found, a zero is returned. 
If the ID is found, the 


token for that node is returned. 


At this point an overview of the configuration 
process 


is needed. A more detailed coverage of the process of 
configuring 
an iRMX 86 system is provided in the 


manual 
entitled 
"iRMX 86 Configuration 
Guide for 


ISIS-II Users." 


For each iRMX 86 application, 
the following steps 


must be performed. 


1) Program code for each task in the system must be 


written and compiled or assembled. 


2) A memory map for the software must be drawn up. 
3) The system software must be linked and located. 
4) The application jobs must be linked and located. 
5) Tables of configuration data must be drawn up. 
6) The tabular 
data from step 5 must be formatted 


into a memory data block through the use of a set 
of ASM-86 macros 
provided 
with 
the iRMX 86 


product. 


7) The root job must be linked and located. 


The code executed by the root task is part of the iRMX 
86 system code. This task is initially the only task in 
the system. The root task will access the data block 
constructed by the ASM-86 macros and will create the 
user jobs specified by the macros. The data for the 
configuration 
process 
for example 
1 is shown 
in 


AppendixB. 


The first 
page diagrams 
the memory 
map for the 


example. The iterative 
link and locate process to put 
these pieces together begins on the second page. The 
LINK86 
and 
LOC86 
commands 
shown 
place 
the 


iRMX/86 nucleus into memory. 
The LOCATE map 


indicates that the last memory location used by the 
nucleus was 077DFH. Therefore, the next contiguous 
piece, the I/O system, is located at 077EOH. 


This process is repeated for the remainder of the jobs 
in the system. 


When the link and locate process is complete, 
the 


information 
for the ASM-86 macros must be brought 


together. 
Worksheets 
are provided in the iRMX 86 
configuration guide to simplify this process. 


The filled-out worksheets for the macros are shown in 
the appendix. A configuration 
file is constructed using 


the editor and th!l worksheet information is entered 
into this file. When the file is complete, the con- 
figuration 
table is created by assembling the file 
CTABLE. A86. This file accesses the configuration file 
built earlier. 


The configuration tables are then linked and located 
together with the code for the root task and the system 
generation process is complete. 


INIT$IO AND FINISH$IO 
The start$and$finish 
module (5.1-5.371) contains the 


code for 
the 
init$534$io 
and finish$534$io 
pro- 


cedures. The init$534$io 
procedure creates a seg- 


ment, shown in Figure 23, which is used to hold the 
various pieces of information 
needed by the other 


driver 
procedures 
(5.323). The discussion of this 


procedure in Chapter 4 pointed out that any errors 
encountered in the initialization are indicated by the 
non-zero status and that the assumption is made that 
any partial creations must be cleaned up by the init$io 
procedure. This assumption is carried out by the check 
at line 5.324 (and the others at 5.331, 5,335, 5.339 and 
5.342). 
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The device information contained in the device unit 
information block for this device is retrieved in line 
5.328-5.329. A mailbox to be used for sending 1/0 
request segments to the 110 handler tasks is created in 
line 5.330. The interrupt task for this job is created by 
the call in line 5.337. 


The do loop starting at line 5.340 is executed to create 
eight semaphores to be used by the interrupt task to 
indicate the occurrence of an interrupt. Note that the 
initial value of the semaphore is zero (no interrupt 


pending) and the maximum value is one. Since the 
nature of the 8251 USART device does not support 
buffering, when a new character overruns the previous 
character before the interrupt 
can be serviced, the 


data is lost. Therefore, there is no need to indicate the 
occurrence of multiple interrupts pending on the same 
device. 


The call at line 5.345 initializes the programmable 
devices on the iSBC 534 board. If execution has 
proceeded to line 5.346, the initialization is complete 
and a zero status is returned. If an error occurred at 
any point, the code in lines 5.348-5.356 will clean up 
the partial initialization. 


Thefinish$534$io 
procedure (5.358-5.370) undoes the 


work of the init$534$io 
procedure. The segment, 


mailbox, 
interrupt 
task 
and 
semaphores 
are 
all 


deleted. 


The queue$534$io 
procedure is shown in lines 6.1- 


6.382. In line 6.322 the function field of the 1/0 
request segment is checked to see if it is within 
bounds. If it is not, a bad status code is returned. If the 
function is valid, a do case block is executed using the 
function code as the index. 


If a read request is encountered, the auxiliary pointer 
is set to point to the ret$data 
structure 
(initialized 


earlier by the init$534$io procedure). In line 6.327 the 
segment is then sent to the request mailbox to be 
received and processed by an 110 processor task. In 
lines 6.330-6.334 the same action is taken with write 
requests. 


Since this driver does not support seeking and special 
functions, the code for these two cases simply returns 
an error condition. 


In the case of an attach$device 
call, the code in lines 


6.341-6.361 is executed. First, 
two 1/0 processing 


tasks are created. All of these tasks execute identical 
code and each task is capable of servicing a read or a 
write request on any 8251. Two tasks are created for 
each 8251 device so that the peak load can always be 
handled (that is, all receivers and transmitters' going 
simultaneously). Lines 6.346-6.357 perform the initi- 
alization of the 8251 USART and the baud rate gen- 
erators for this channel. The calls in line 6.358 and 
6.359 accept an interrupt 
and a character from the 


semaphore associated with the receiver just initialized. 
This is done to clear off an interrupt generated by the 
8251 whenever it is initialized. 


In the case of a detach$device 
call, the code in lines 


6.363-6.367 sends the 
110 request segment to the 


request mailbox twice. This is done to signal two of the 
110 handler tasks to delete themselves. As discussed 
earlier in the attach$device 
section, none of the 110 
handler tasks is any different from any of the others. 
There are two created for each 8251 device which is 
attached. The protocol set up for their deletion is 
shown here. When an 110 handler task receives a 
segment 
of type "detach$device" 
it will send the 


segment to the response mailbox and then delete itself. 


The code for the open and close requests is the same. 
Both cases are supported 
but are NOPs since no 
specific action needs to be taken by the driver. 


Lines 6.379-6.382 contain the code for the cancelS 
534$io 
procedure. 
As discussed earlier, 
this 
pro- 


cedure is simply a placeholder and serves no par- 
ticular purpose. 


INTERRUPT 
CONTROL 
MODULE 


The interrupt handler and interrupt task are shown in 
lines 7.1-7.329. The interrupt 
task is the first piece 
executed. It is created by the init$534$io procedure. It 
calls RQ$set$interrupt 
in line 7.325 to indicate to the 
iRMX86 nucleus that it is an interrupt task. 


Once the initialization is complete, the task enters an 
infinite loop. The call to RQ$wait$interrupt 
in line 
7.322 causes the task to be put into the asleep state 
until an interrupt occurrence is signaled. The task will 
be returned to the READY state when an interrupt 
occurs, the interrupt handler is started, and the call to 
RQ$signal$interrupt 
is executed at line 7.312. The 


current interrupt level is then determined by polling 
the 8259 chip on the iSBC 534 board. Using the 
encoded level number, a unit is sent to the appropriate 
semaphore to indicate that an interrupt is pending. 


110 TASK 


The final procedure that makes up this driver contains 
the code for the tasks that perform the actual 1/0 to 
the iSBC 534 board. The loop executed by each task 
starts by waiting at the request mailbox for an I/O 
request segment. When the segment is sent by the 
queue$534$IO procedure, its function code is checked 
(line 8.327, 
8.332, 
8.340). If the 
function 
is f$ 
detach$device, 
the task sends the segment to the 
response mailbox and then deletes itself. 


If the request was for a read, the task fills the buffer 
with input data. The call at line 8.334 waits for a unit 
at the semaphore which will indicate a receiver ready 
on the input line. When the unit is sent by the in- 
terrupt task, the character is read in, the pointers and 
counts are updated, and another unit is requested. 


The last request which is recognized by the 110 task is 
for a write operation. The code for this request is 
almost identical to the code for a read request. An 
interrupt from the transmitter 
is awaited, a character 


is output and the counts are updated in lines 8.341- 
8.346. 


Once the request is fulfilled, the message is sent to the 
response exchange in line 8.350. 


The configuration of this system is studied next. The 
code for the iSBC 534 driver is linked directly to the 
rest of the I/O system libraries. 
The entry 
point 


addresses for the queue$534$io, 
cancel$534$io, init$ 


534$io, and finish$534$io 
procedures are declared in 


the IOCNFG.A86 file on the I/O system disk. This file 
also contains the device unit information block (DUIB) 
structures for the four units on the iSBC 534 board. 
The unique information for the iSBC 534 device and 
the units on the device is contained in the device and 
unit information tables. Pointers to these tables are 
contained 
in 
the 
DUIB 
structures. 
All 
of 
this 


information is shown in Figure 24. 


The submit file used to build an I/O system using the 
iSBC 534 driver is shown in Figure 25. The file 
DRV534.LIB contains the object files generated by 
PLlM-86 and ASM-86 from the source code shown in 
modules 5-9. 


This application note is an introduction to the iRMX 
86 Operating System. The requirements of operating 
systems were studied along with traditional solutions. 
Following this, the iRMX 86 Operating System was 
introduced and its correlation with the requirements 
was studied. 


Later in the application note, the topic of system 
design was covered. Example solutions were studied to 
solidify 
a methodology 
for 
solving 
application 


problems and then the code for these solutions was 
discussed to gain insight into the details of imple- 
menting iRMX86 systems. 


The purpose 
of a configurable, 
real-time, 
multi- 


purpose operating system is to provide a solid foun- 
dation for application software. The iRMX 86 system 
provides this foundation, giving the software engineer 
a means to quickly and easily implement new designs. 
In addition, the iRMX 86 architecture is the bridge to 
future technology providing the designer with an up- 
grade path to future hardware and software products. 
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; 
unit 
534 
0 
info 
db 
dw 


unit 
info: 
iSBC 
534.1 


~nit 
534 
1 
info 
db 
- 
dw 


; 
unit 
534 
2 
info 
rib 
dw 


; 
asm86 
:f1:iocnfg.a86 
date(%0) 
print(:f5:iocnfg.lst) 
link86 
&. 


:fl:ios.1ib(ioinit), 
& 
: f 1: iocnfg 
.obj,.E.. 


:fl:ios.lib, 
& 
:fl:drv534.lib, 
& 


:f4:rpifc.lib 
& 
to 
:fl:ios.lnk 
map 
print(:fl:ios.mpl) 
loc86 
:fl:ios.lnk 
to 
:f1:ios 
map 
se()) 
print(:f1:ios.mp2) 
&. 


oc(noli,nopl,nocm,nosb) 
& 


order(elasses(code,data,stack,memory») 
& 
addresses(classes(code(%l»)) 
& 
segsize(stack(0» 
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APPENDIX A 
Code Listings 


ISIS-II 
PL/M-86 
V2.0 
€OMPILATION 
OF 
MODULE 
LISTENERMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:listen.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:listen.plm 
PRINT(:Fl:LISTEN.LST) 


DEBUG 
COMPACT 
OPTIMIZE(3) 
ROM 
DATE(5/28/se 


listener$module: 
do; 


This 
task 
creates 
segments, 
sends 
them 
to 
the 
input 
service 
job 
to be 
filled 
with 
input 
packet 
info. 
Upon 
response 
the 
info 
is checked 
to 
see 
what 
action 
needs 
to 
be 
taken. 


If a 
log$on 
request 
is sensed, 
a worker 
task, 
service 
mailbox, 
and 
response 
mailbox 
are 
created 
and 
the 
packet 
is 


sent 
along 
to 
the 
worker 
task. 
If a log$off 
is sensed 
all 


local 
reference 
to 
the 
workstation 
is deleted 
and 
the 
packet 


is sent 
along 
to 
tell 
the 
worker 
to delete 
himself. 
If an 
1/0 
request 
is sensed 
the 
station 
ID is checked 
to make 


sure 
it 
is logged 
on. 
If 
it 
is, 
the 
packet 
is sent 
along 
to 
the 
worker. 
If it 
isn't 
an 
error 
packet 
is sent 
back 
to 
the 
requesting 
workstation. 


$include(:f2:common.lit) 
$SAVE 
NOLIST 


$include(:fl:node.lit) 
1* literal 
declaration 
o~ 
node 
descriptor 
for 
list 
utilities 
*1 


declare 
node 
literally 
'structure( 


link$f 
word, 


link$b 
word, 


workSstationSID 
word, 


service$mbox$t 
word, 


worker$task$t 
word, 
resp$mbox$t 
word) '; 


$ include (:f1:1stutl .ext) 
1* external 
declarations 
for 
list 
manipulation 
utilities 
*1 


$save 
nolist 


$ include(: f 1:po intr .ext) 
1* external 
declaration 
of 
pointerize 
procedure 
*1 
$save 
nolist 
$include(: f1:rqpckt.lit) 
1* literal 
declaration 
for 
request 
packet 
structure 
*1 


declare 
req$segment$struc 
literally 
'structure( 


funct 
word, 
count 
word, 


actual 
word, 


ex$val 
word, 


work$station$ID 
word, 


cmd 
wo rd, 


share 
word, 


mode 
word, 


status 
word, 


fileSname 
(64) byte, 


buf 
(128) 
byte)'; 


$include( 
:f2:nucprm.ext) 


$SAVE 
NOLIST 


worker$task: 
procedure 
external; 


end 
worker$task; 


324 


325 
2 


326 
2 


327 
2 


328 
2 
329 
2 


33'l 


331 
2 


332 
2 
333 
2 


declare 
begin$listener$task$data 
byte 
public, 


begin$worker$task$data 
byte 
external, 


log$on$info$mbox$t 
token 
public, 


ex$ val 
word, 
log$on$mbox$name 
(7) 
byte 
data(6,'LOG$ON'), 


packet$size 
literally 
'132', 
f$read 
literally'S', 


f$write 
literally 
'6', 


log$on 
literally 
''l', 
log$off 
literally 
'1', 


not$logged$on 
literally 
'1', 


(root$ jobS t, input$ request$mbox$ 
t) 
token, 
(output$ 
request$mbox$ 
t, resp$mbox$ 
t) 
token, 


(wo rk$stat ion $ 1 ist$ roo t$ t ,req$ seg men t$ t) 
to ken, 


(1og$ on$ in fo$ seg$ t I d ummy$ t, ws$d esc$ t) 
to ken, 


(req$ 
segmentS 
p, wo rk$stat ion$l ist$ roo t$ p) 
po inter, 
(log$on$ 
info$ seg$p ,data$ seg$p,ws$desc$p) 
po inter, 
(req$ segment 
based 
req$ segmentS 
p) 
req$ segmentS 
st ruc, 
(work$station$list$root 
based 
work$station$list$root$p) 
node, 


(log$on$info$seg 
based 
log$on$info$seg$p) 
node, 
data$seg$p$o 
structure(offset 
word, 
base 
word) 
at(@data$seg$p) 
I 
(ws$desc 
based 
ws$desc$p) 
node; 


req$segment.funct=f$write; 
req$segment.status=not$logged$on; 
call 
rq$send$message(outputSrequest$mbox$t,req$segment$t,'l,@ex$val); 


return; 
end; 


10gSon$info$mbox$t=rq$create$mailbox('l,@ex$val); 
root$job$t=rq$get$task$tokens(3,@ex$val); 
input$request$mbox$t=rqSlookJp$object( 


/* 
job 
*/ 
root$job$t, 


/* 
name 
*/ 
@(9,'INPUT$REQ'), 


/* 
time 
limit 
*/ 
'lFFFFH, 


/* 
status 
ptr 
*/ 
@ex$val); 


output$request$mbox$t=rq$lookup$object( 


/* 
job */ 
root$job$t, 


/* 
name 
*/ 
@().'l,'OUTPUT$REQ') 
I 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
status 
ptr 
*/ 
@ex$val); 


resp$mbox$t=rq$createSmailbox(0,@ex$val) 
; 
work$station$list$root$t=rq$create$segment(16,@ex$val); 
wo rk$stat ion $ 1 is t$ roo t$p= po inte ri ze (wo rkSsta ti 0 n$ 1 ist$ roo t$ t) ; 
workSstation$list$root.link$f, 
work$stationSlist$root.link$b=work$station$list$root$t; 
work$station$listSroot.workstation$ID='l; 


req$segment$t 
= 
rqSreceive$message( 


/* mbox 
token 
*/ 
input$request$mboxSt, 


/* 
time 
limit 
*/ 
'lFFFFH, 


/* 
response 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


req$segmentSp=pointerize(reqSsegmentSt) 
; 


if 
req$segment.cmd= 
10gSon 
then 
do; 


else 
if req$segment.cmd 
= 
log$off 
then 
do; 


else 
do; 


log$on$info$seg$t=rq$create$segment( 
/* 
size 
*/ 
16, 


/* 
status 
ptr*/ 
@ex$val}; 


log$on$info$seg$p=pointerize( 
log$on$info$seg$t); 
log$on$info$seg.service$mbox$t= 
. 


rq$create$mailbox(0,@ex$val}; 
log$on$info$seg.resp$mbox$t= 
rq$create$mailbox(0,@ex$val); 
log$on$info$seg.work$station$ID= 
req$segment.work$station$ID; 
data$seg$p=@begin$worker$task$data; 
log$on$info$seg.worker$task$t= 
rq$create$task( 
/* 
priori ty */ 
/* 
start 
addr 
*/ 
/* 
data 
seg 
ptr 
*/ 
/* 
stack 
pointer 
*/ 
/* 
stack 
size 
*/ 
/* 
task 
flags 
*/ 
/* 
status 
ptr 
*/ 


200, 
@worker$task, 
data$seg$p$o.base, 
0, 
500, 
0, 
@ex$val) ; 


call 
rq$send$message( 


/* mbox 
token 
*/ 
log$on$info$mbox$t, 


/* 
object 
token 
*/ 
log$on$info$seg$t, 


/* 
response 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val}; 


logSon$info$seg$t=rq$rece(ve$message( 
/* 
mailbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
response 
token 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val}; 


call 
insert$on$list(work$station$list$root$t, 
log$on$info$seg$t) 
; 
call 
rq$send$message( 


/* mbox 
tok 
*/ 
log$on$info$seg.service$mbox$t, 
/* 
obj 
tok 
*/ 
req$segment$t, 


/* 
response 
*/ 
0, 


/* 
status 
*/ 
@ex$val); 


ws$desc$t=search$list(work$stationSlist$root$t, 


req$segment.work$station$ID); 
if ws$desc$t 
= 
0 then 
call 
return$error$to$WS; 
else 
do; 
ws$descp=pointerize(ws$desc$t) 
; 


call 
delete$from$list( 
ws$desc$t); 
call 
rq$send$message( 
ws$desc.service$mbox$t, 
req$segment$t, 
0, 
@ex$val) ; 


ws$desc$t=search$list(work$station$list$root$t,. 


req$segment.work$station$ID); 


if ws$desc$t=0 
then 
call 
return$error$to$WS; 
else 
do; 
ws$descp=pointerize(ws$desc$t) 
; 
call 
rq$send$message( 
ws$desc.service$mbox$t, 
req$ segmentS t, 
0, 
@ex$val); 


end; 


call 
rq$delete$segment(req$segment$t,@ex$val); 
end; 
/* of do 
forever 
*/ 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
694 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


0281H 
0000H 
002BH 
0018H 


641D 
0D 
43D 
24D 


ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
WORKERTASK 
OBJECT 
MODULE 
PLACED 
IN 
:FI:worker.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:FI:worker.plm 
PRINT(:FI:WORKER.LST) 
DEBUG 
COMPACT 
OPTIMIZE(3) 
ROM 
DATE'(5/28/80) 


worker$task: 
do; 


This 
module 
contains 
the 
code 
executed 
by 
the 
worker 
tasks. 
When 
started, 
the 
task 
goes 
to 
a mailbox 
to 
receive 
a segment 
containing 
initialization 
information. 
Using 
this 
information 
the 
task 
services 
a ~ervice 
mailbox 
performing 
any 
I/O 
functions 
requested 
of 
it. When 
a 
log$off 
request 
comes 
in the 
worker 
task 
closes 
and 
detaches 
the 
file 
and 
deletes 
itself. 


$include( 
:fl:nucprm.ext) 
$SAVE 
NOLIST 
$include(:f 
1:iosys.ext) 
$save 
nolist 
$include(:fl:node.lit) 
/* 
literal 
declaration 
of 
node 
descriptor 
for 
list 
utilities 
*/ 
$save 
nolist 
$include(:f2:common.lit) 
$SAVE 
NOLIST 
$include(:fl:pointr.ext) 
/* 
external 
declaration 
of 
pointerize 
procedure 
*/ 
$save 
nolist 
$include(:fl:rqpckt.lit) 
/* 
literal 
declaration 
for 
request 
packet 
structure 
*/ 


declare 
read 
literally 
'1', 
write 
literally'S', 
log$on 
literally 
'2', 
log$off 
literally 
'3', 
(log$on$info$mbox$t,output$request$mbox$t) 
token 
external; 


declare 
(log$on$info$seg$t,log$on$resp$mbox$t,resp$mbox$t, 
root$job$t,user$object$t,prefix$t,iors$t, 
se rv ice$mbox$ t,conn$ t,req$ seg$ t) to ken, 
(log$on$info$p,req$seg$p) 
pointer, 
(req$seg 
based 
req$seg$p) 
req$segment$struc, 
(log$on$info 
based 
log$on$info$p) 
node, 
(dummy$t,ex$val,work$station$ID) 
word; 


log$on$info$seg$t=rq$receive$message( 
/* mbox 
token 
*/ 
log$on$info$mbox$t, 
/* 
time 
limit 
*/ 
0FFFFH, 
/* 
response 
ptr 
*/ 
@log$on$resp$mbox$t, 
/* 
status 
ptr 
*/ 
@ex$val) ; 


log$on$info$p=pointerize(log$on$info$seg$t) 
; 
service$mbox$t=log$on$info.service$mbox$t; 
resp$mbox$t=log$on$info.resp$mbox$t; 
work$station$ID=log$on$info.work$station$ID; 


call 
rq$send$message( 


/* mbox 
token 
*/ 
log$on$resp$mbox$t, 


/* 
object 
token 
*/ 
log$on$info$seg$t, 


/* 
response 
token 
*/ 
0, 


/* 
status 
ptr 
*/ 
@ex$val) ; 


root$job$t=rq$get$task$tokens(3,@ex$val); 
user$object$t=rq$lookup$object( 
/* 
job 
token 
*/ 
root$job$t, 
/* 
name */ 
@(ll,'USER$OBJECT'), 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
status 
ptr 
*/ 
@ex$val) ; 
prefix$t=rq$lookup$object( 
/* 
job 
token 
*/ 
root$job$t, 


/* 
name */ 
@(6,'PREFIX'), 


/* 
time 
limit. */ 
0FFFFH, 


/* 
status 
ptr 
*/ 
@ex$val); 


req$seg$t=rq$receive$message( 
/* mailbox 
token 
*/ service$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
response 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


if 
req$seg.cmd=logSon 
then 
do; 
call 
rq$a$attach$file( 


/* user 
object 
*/ 
user$object$t, 


/* 
prefix 
token 
*/ 
prefix$t, 


/* 
pathname 
*/ 
@req$seg.file$name, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummySt, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$segment(iors$t,@exSval); 


call 
rq$a$open( 


/* connection 
*/ 
conn$t, 


/* mode 
*/ 
req$seg.mode, 


/* 
share 
*/ 
req$seg.share, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rqSreceive$message( 
/* mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$deleteSsegment(iors$t,@ex$val); 


reqSseg.status=0; 
call 
rq$send$message( 


/* mbox 
token 
*/ 
output$request$mbox$t, 


/* 
object 
token 
*/ 
req$seg$t, 


/* 
resp 
ptr 
*/ 
0, 


/* status 
ptr 
*/ 
@ex$val); 
end; 


else 
if 
req$seg.cmd=log$off 
then 
do; 


call 
rq$a$close( 


/* connection 
*/ 
/* 
resp 
token 
*/ 


/* 
status 
ptr */ 


conn$t, 
resp$mboxSt, 
@ex$val) ; 


iors$t= 
rq$receive$message( 


/* mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@exSval); 
call 
rq$delete$segment(iors$t,@ex$val); 
call 
rq$a$delete$connection( 


/* 
connection 
*/ 
connSt, 


/* 
response 
ptr 
*/ 
resp$mbox$t, 


/* status 
ptr */ 
@ex$val); 
iors$t=rq$receiveSmessage( 
/* mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
~FFFFH, 


/* 
response 
ptr 
*/ 
@dummySt, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$deleteSsegment(iorsSt,@exSval); 
call 
rq5deleteSmailbox(service$mbox$t,@ex$val); 
call 
rq$deleteSmailbox(respSmboxSt,@ex$val); 
req$seg.status=0; 
call 
rq$sendSmessage( 
/* mbox 
token 
*/ 
output$request$mbox$t, 
/* object 
token 
*/ 
req$segSt, 
/* 
resp 
token 
*/ 
0, 
/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$task(0,@ex$val); 
end; 


else 
if 
req$seg.cmd=read 
then 
do; 


call 
rqSaSread( 


/* connection 
*/ 
conn$t, 


/* 
buf 
ptr 
*/ 
@reqSseg.buf, 


/* count 
*/ 
req$seg.count, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rqSreceiveSmessage( 
/* mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$deleteSsegment(iors$t,@ex$val); 
req$seg.status=~; 
call 
rq$sendSmessage( 


/* mbox 
token 
*/ 
output$request$mbox$t, 
/* 
object 
token 
*/ 
req$segSt, 
/* 
resp 
token 
*/ 
~, 
/* status 
ptr 
*/ 
@exSval); 
end; 


else 
if 
req$seg.cmd=write 
then 
do; 


call 
rqSa$write( 
/* connection 
*/ 
conn$t, 
/* 
buf 
ptr 
*/ 
@req$seg.buf, 
/* 
count 
*/ 
req$seg.count, 
/* 
resp 
token 
*/ 
resp$mbox$t, 
/* 
status 
ptr 
*/ 
@ex$val) ; 
iorsSt=rq$receive$message( 
/* mbox 
token 
*/ 
resp$mbox$t, 
/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


/* status 
ptr 
*/ 
@exSval); 
call 
rq5delete$segment(iors$t,@ex$val); 


call 
rq$send$message( 
/* mbox 
token 
*/ 
output$request$mbox$t, 


/* object 
token 
*/ 
req$seg$t, 
/* resp 
token 
*/ 
0, 
/* 
status 
ptr 
*/ 
@ex$val); 
end; 
end; 
/* of 
do 
forever 
*/ 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
717 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


0288H 
0000H 
0000H 
0?-34H 


6480 
flD 
0D 
520 


ISIS-II 
MCS-86 
MACRO 
ASSEMBLER 
V2.0 
ASSEMBLY 
OF 
MODULE 
POINTR 


OBJECT 
MODULE 
PLACED 
IN 
:F1:POINTR.OBJ 


ASSEMBLER 
INVOKED 
BY: 
asm86 
:f1:pointr.a86 
debug 
pr(:fS:pointr.lst) 


LINE 
SOURCE 


1 
Stitle(pointerize 
Utility) 


2 
arg 
off 
equ 
4 
; set 
args 
for 
"DELUXE" 


3 
4 
code 
segment 
word 
public 
'CODE' 


5 
code 
ends 


fi 
7 
cg roup 
9 roup 
code 


e 
code 
segment 


9 
assume 
cs: 
cg roup 


10 
11 
pointerize 
proc 
near 


12 
public 
pointeri ze 


13 
push 
bp 
save 


]4 
mov 
bp, 
sp 
mark 
stack 
]5 
16 
token 
equ 
word 
ptr 
[bp + 
arg 
off 
+ III 
17 
-- 


18 
mov 
es, 
token 
get 
base 


]9 
xo r 
bx, 
bx 
zap 
offset 


2" 
21 
mov 
sp, 
bp 
restore 
stack 


22 
pop 
bp 


23 
ret 
2 


24 
pointeri ze 
endp 


25 
code 
ends 


26 
end 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF MODULE 
LISTUTILITIESMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:lstutl.OBJ 


COMPILER 
INVOKED 
BY: 
plm86 
:Fl:lstutl.plm 
PRINT(:F5:LSTUTL.LST) 


DEBUG 
COMPACT 
OPTIMIZE(3} 
ROM 
DATE(3/7/8~) 


list$utilities$module: 
do; 


This 
module 
contains 
three 
list 
manipulation 
utilities. 
Insert$on$list 
takes 
the 
given 
node 
and 
inserts 
it on 
the 
list 
indicated 
by 
the 
root 
node 
parameter. 
Delete$from 
list 
unlinks 
the 
indicated 
node 
from 
the 
list 
it 
is 


linked 
to. 
SearchSlist 
scans 
the 
list 
from 
the 
root 
looking 


for 
the 
indicated 
node. 
If 
found, 
the 
token 
for 
the 
node 


is 
returned. 
If not 
found, 
a 
zero 
is returned. 


Sinclude(:f4:common.lit) 
$SAVE 
NOLIST 


Sinclude(:fl:node.lit) 
1* 
literal 
declaration 
of 
node 
descriptor 
for 
list 
utilities 
*/ 


$save 
nolist 
S incl ude(: f1:pointr .ext} 
1* external 
declaration 
of 
pointerize 
procedure 
*1 
Ssave 
nolist 


declare 


(rootS t ,newSdescS t,fwdSdescS t) 
token, 


(root$ p ,newSdescS P. fwdSdescS p) 
po inter, 


(root 
based 
root$p) 
node, 


(newSdesc 
based 
newSdescSp) 
node, 


(fwdSdesc 
based 
fwdSdescSp) 
node; 


root$p:pointerize(rootSt); 
new$descSp:pointerize(newSdesc$t); 
fwd$desc$t:root.link$f; 
fwd$descSp:pointerize(fwdSdesc$t) 
; 
root.linkSf:new$descSt; 
new$desc.linkSf:fwd$descSt; 
newSdesc.linkSb:root$t; 
fwdSdesc.linkSb:newSdescSt; 
return; 


declare 


descSt 
token, 


(descSp,bSdescSp,f$descSp) 
pointer, 


(desc 
based 
desc$p) 
node, 


(bSdesc 
based 
bSdescSp) 
node, 


(fSdesc 
based 
fSdescSp) 
node; 


descSp:pointerize(desc$t); 
bSdescSp:pointerize(desc,linkSb); 
fSdescSp:pointerize(desc.linkSf); 
b$desc.linkSf:desc.linkSf; 
fSdesc.link$b:desc.linkSb; 
return; 


declare 


(rootSt,WSSID) 
word, 


(sSdescSp,rootSp) 
pointer, 


(root 
based 
rootSp) 
node, 


(sSdesc 
based 
sSdescSp') node, 


sSdescSpSo 
structure 
(offset 
word, 
base 
word) 
at(@sSdesc$p), 


temp 
pointer; 


s$descSp=pointerize(rootSt); 


next$node: 
if s$desc.work$stationSID=WSSID 
then 
return 
sSdescSpSo.base; 
if sSdesc.linkSf 
= 
root$t 
then 
return 
0; 
temp=pointerize(sSdesc.linkSf); 
sSdescSp=temp; 
goto 
nextSnode; 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
114 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


00FEH 


il'il'0C1H 
0000H 
0018H 


254D 
f1D 
f1D 
24D 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
STARTANDFINISH 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:strfin.OBJ 


COMPILER 
INVOKED 
BY: 
plm86 
:Fl:strfin.plm 
PRINT{:F5:STRFIN.LST) 


DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE{4/28/80) 


314 
315 
316 


317 
318 


start$and$finish: 
do; 


This 
module 
contains 
the 
init$534$IO 
and 
the 
FINISHS534$IO 
procedures 
which 
can 
be 
called 
by 
the 
RMX/86 
I/O 
system. 
STARTSIO 


is 
called 
just 
before 
the 
first 
attachSdevice 
is performed. 
It will 
create 
the 
interrupt 
task 
and 
the 
eight 
interrupt$pending 


semaphores. 
The 
FINISH$IO 
procedure 
is called 
just 
after 
the 
last 
detach$device 
is performed. 
It undoes 
everything 
the 
START$IO 


call 
did. 


$include( 
:f4:nucprm.ext) 
$SAVE 
NOLIST 
$ incl ude (:f4:common.l it) 
$SAVE 
NOLIST 
$include(: f l:duib.l it) 
/* duib 
structure 
definition 
*/ 


$save 
nolist 
$include( 
:f4:nerror.l 
it) 


$SAVE 
NOLIST 


$include{:f 
l:pointr .ext) 
/* external 
declaration 
of 
pointerize 
procedure 
*/ 


$save 
nolist 


$include(:f 
1:retdta.l it) 


/* 
literal 
declaration 
of 
retSdata 
structure 
for 
init$534Sio 
*/ 


$save 
nolist 


init$534$hw: 
procedure{data$p) 
external; 
declare 
data$p 
pointer; 
end 
init$534$hw; 
/* 
initializes 
534 hardware 
*/ 


int$534$task: 
procedure 
external; 
end 
int$534Stask; 


declare 


begin$int$534$data 
byte 
external, 


IO$base$addr 
byte 
public, 


int$level.word 
public, 


g$ret$data$p 
pointer 
public, 
req$mbox$t 
token 
pUblic; 


init$534$IO: 
procedure(duib$p,ret$data$t$p,status$p) 
reentrant 
public; 


declare 


(duibSp,retSdaraStSp,statusSp) 
pointer, 


(duib 
baseCl duibSp) 
C1ev$unitS infoSblock, 


(retSdataSt 
baseCl retSdataStSp) 
token, 


(status 
baseCl statusSp) 
word, 


devSinfoSp 
pointer, 


rlevSinfo 
based 
rlevSinfoSp 
structure( 
level 
word, 


priority 
byte, 


IOSbaseSaddr 
byte), 


322 
2 


323 
2 
324 
2 
325 
2 
326 
2 
327 
2 
328 
2 


329 
2 


33~ 
2 


331 
2 
332 
2 


333 
2 


334 
2 


335 
2 


336 
2 
337 
2 


342 
3 


343 
3 


344 
3 
345 
2 
346 
2 
347 
2 


348 
2 


349 
3 
35~ 
3 
351 
2 


352 
2 


353 
2 


354 
2 


ex$val 
word, 


oata$seg$p 
pointer, 


data$seg$p$o 
structure(offset 
woro,base 
word) 
at(t<ldata$seg$p}, 


(i,j) 
byte; 


declare 


ret$dataSp 
pointer, 


ret$data 
based 
retSdataSp 
structure(ret$dataSstruc); 


ret.$data$t=rq$createSsegMent 
(si ze (retSdata) ,f"exSval}; 


if ex$val 
<> 
~ then 


goto 
err~; 


gSret$dataSp,retSdataSp=pointerize(retSdataSt); 
devSinfoSp=duib.nevSinfo$p; 
IO$base$addr,ret$data.IOSbase=devSi~fo.IOSbase$addr; 
int$level,retSdata.intSlevel=cevSinfo.level; 


ret$data.requestSmbox$t,reqSmboxSt 


=rq$createSmaiJbox(0,(ilexSval} 
; 


if exSval 
<> 
~ then 


goto 
errl; 


ret$data.respSmbox$t=rqScreateSmailbox(0,t<lexSval}; 
if exSval 
<> 
0 then 
goto 
err2; 
1* clean 
up 
partial 
creation 
*1 


data$seg$p=lilbeginSintS534Sdata; 
ret$data.intStaskSt=rqScreateStask( 


1* priority 
*1 
devSinfo.prio·rity, 


/* entry 
point 
*1 
0intS534Stask, 


1* data 
segment 
*1 
dataSsegSpSo.base, 


1* stack 
pointer 
*1 ~, 


1* stack 
size 
*1 
40~, 


1* task 
flags 
*1 
0, 


1* status 
pointer 
*1 
lilexSval); 
if exSval 
<> 
r then 


goto 
err3; 1* can't 
create. 
clean 
up 
partial 
creation 
*1 


do 
i=0 to 
7; 1* create 
semaphores 
*1 
retSdata.int$sema(i)=rqScreateSsemaphore( 
1* 
initial 
value 
*1 ~, 


1* max 
value 
*1 
1, 


/* priority 
queue 
*1 
1, 


1* status 
ptr *1 
0exSval}; 


if exSval 
<> 
0 then 


end; 
call 
ini t$534Shw( retSdataSp); 


status=ESOK; 
return; 


err4: 


do 
j='l to 
i; 


call 
rqSdeleteSsemaphore(retSdata.int.Ssema(j) 
,status$p); 
end; 
call 
rq$resetS int.errupt (oev$ 
info .level ,statusSp); 


err3: 


call 
rqSceleteSmailbox(retSdata.respSmboxSt,statusSp); 


err2: 


call 
rq$deleteSmailbox(retSdata.requestSmboxSt,statusSp}; 
errl: 
call 
rqSdelet.eSsegment(retSdata$t,status$p); 


31i~ 
2· 
361 
2 


31i2 
2 


31i3 
2 


31i4 
2 
31i5 
2 
366 
3 


31i7 
3 


31i8 
2 


369 
2 


370 
2 


371 
1 


err~: 


status=exSval; 
/~ 
restore 
original 
status 
condition 
*/ 


return; 


end; 
/* of 
procedure 
*/ 


finishS534SIO: 
procedure(duibSp,retSdataSt) 
reentrant 
public; 
declare 
duibSp 
pointer, 


devSinfoSp 
pointer, 


devSinfo 
based 
devSinfoSp 
structure( 
level 
word, 


priority 
byte, 


IOSbaseSaddr 
byte), 


retSdataSp 
pointer, 


retSdata 
baseci 
retSdataSp 
structure( 
retSdataSstruc), 


(duib 
baseci 
duibSp) 
devSunitSinfoSblock, 


retSdataSt 
token, 


i 
byte, 


exSval 
word; 


devSinfoSp=duib.devSinfoSp; 
retSd 
ataS p=po i nte ri ze ( retSd 
ataS t) ; 


call 
rgSresetSinterrupt(devSinfo.level,~exSval); 


call 
rgSdel 
eteSma i 1box ( retSdata. 
r eguestSmhoxS 
t,~ exS va l) ; 
call 
rgSdeleteSmailbox(retSdata.respSmboxSt,~exSval); 
do 
i=~ 
to 
7; 


call 
rgSdeleteSsemaphore( 
retSdata. 
i ntS seMa (i) 
, 


~exSval); 


end; 
call 
rgSdeleteSsegment 
(retSdataSt 
,~exSval); 


return; 
end; 
/* of 
procedure 
*/ 


end 
startSandSfinish; 


ceDE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
671 
LINES 
READ 
~ 
PROGRAM 
ERROR(S) 


0220H 


~f'0(,H 
~~0'lH 
0f'34H 


544D 
00 
"D 
52D 


ISIS-I~ 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
QUEUE53~IOMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:queio.OBJ 
COMPILER 
INVOKED 
BY: 
plm8" 
:Fl:queio.plm 
PRINT(:F5:QUEIO.LST) 


DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE(4/25/80) 


queueS53A$io$module: 


do; 


This 
procedure 
is 
called 
by 
the 
I/O 
System 
to 
queue 
an 
I/O 
request 
to 
the 
534 
board. 
The 
function 
field 
in 
the 
IORS 
is 
used 
to 
determin& 
what 
specific 
action 
to 
take. 
Module 
also 
contains 
a 
dummy 
cancelS534$io 
procedure. 


$ incl ud e (:f 4 :n uc prm. ex t) 
$SAVE 
NOLIST 


$include(:f4:common.lit) 
$SAVE 
NOLIST 


$ in c 1 ud e (:f 4 :n err 0 r .1 it) 


$SAVE 
NOLIST 


$include(: 
f l:pointr 
.ext) 


/* 
external 
declaration 
of 
pointerize 
procedure 
*/ 
Ssave 
nolist 


$ inc 1 ud e (:f 1 :d 'lib.1 it) 
/* 
duib 
structure 
definition 
*/ 
$save 
nolist 


$ in c 1 ud e (:f 1 :i0 rs. 1 it) 
/* 
literal 
declaration 
for 
iors 
*/ 


$save 
nolist 


$ incl ud e (:f 1: retd ta .1 it) 
/* 
literal 
declaration 
of 
ret$data 
structure 
for 
initS534Sio 
*/ 
$save 
nolist 


io$534$task: 
procedure 
external; 


end 
io$534$task; 


declare 


begin$ioStaskSdata 
byte 
external; 


decl a,re 


(iors$t,ret$data$t) 
token, 
data$seg$p 
pointer, 
data$seg$p$o 
structure(offset 
word,base 
word) 
at(@data$segSp), 


IDDR 
1 iterally 
•2AH', 
(duib$p,ret$dataSp,iorsSp) 
pointer, 
(duib 
based 
duibSp) 
devSunit$infoSblock, 
(retSdata 
based 
!etSdataSp) 
structure( 
ret$data$struc), 
(iors 
based 
iorsSPi 
rOSr0questS 
res'lltSse']ment, 


10~tnskSt 
token, 


unitSinfoSp 
pointer, 


unitSinfo 
based 
unitSinfoSp 
structure( 
usartScmd 
byte, 
b a un S rat e 
wo rd) , 


I 
byte. 


rIummySt 
token, 


exSval 
word; 


iorsSp=pointeri 
ze (iorsSt); 
retSdataSp=pointerize(retSdataSt); 


if 
iors.funct 
> 
7 then 
goto 
badSrequest; 


do; 
/* 
case 
~-- 
read 
*/ 
ior s.a uxS p= retSdataS p; 
call 
rqSsendSmessage( 
/* 
mbox 
*/ 
retSdata.requestSmboxSt, 
/* 
token 
*/ 
iorsSt, 
/* 
resp 
*/ 
~, 
/* 
status 
ptr*/ 
@exSval); 
return; 
end; 


328 
329 


330 
331 
332 


do; 
/* 
case 
1-- write 
*/ 
i0 rs •a uxSp= retSdataSp; 
call 
rqSsendSmessage( 
/* 
mbox 
*/ 
retSdata.requestSmbox$t, 


/* 
token 
*/ 
iorsSt, 
/* 
resp 
*/ 
0, 
/* 
status 
ptr*/ 
@exSval); 
return; 
end; 


333 
4 
334 
4 


335 
3 
336 
4 
337 
4 


338 
3 
339 
4 
340 
4 


341 
3 


342 
4 


343 
4 
344 
5 


do; 
/* 
case' 2--seek 
(illegal) 
*/ 
goto 
badSrequest; 
end; 


do,; /* 
case 
3-- 
special 
(illegal) 
*/ 
goto 
badSrequest; 
end; 


dataSsegSp=@beginSIOStaskSdata; 
do 
i=0 
to 
1; 
ioStaskSt= 
rq$createStask( 
/* 
priority 
*/ 
150, 
/* 
entry 
pnt 
*/ 
@ioS534Stask, 
/* 
data 
seg 
*/ 
dataSsegSpSo.base, 
/* 
stack 
ptr 
*/ 
0, 


/* 
stack 
size 
*/ 


/* 
task 
flags 
*/ 


/* 
status 
ptr 
*/ 


500, 
0, 
flexSval); 


345 
5 


346 
4 
347 
4 
348 
5 
349 
5 
350 
4 
351 
4 


352 
4 
353 
4 
354 
4 


355 
4 


356 


unitSinfoSp=duib.unitSinfoSp; 
do 
i=0 
to 
3; 
output(retSdata.usartScmd$port(iors.unit))=0; 


end; 
output(retSdata.usartScmd$port(iors.unit))=40H; 
output(retSdata.usartScmdSport(iors.unit) 
)= 
unitSinfo.usartScmd; 
output(ret$data.usartScmdSport(iors.unit) 
)=27H; 
output(retSdata.IO$base+0CH)=O; 
/* 
select 
cntrl 
blk 
*/ 


output(retSdata.timerScmdSport( 
iors.unit»)= 
retSdata.t 
imer$cmd (iors.uni t); 
output(retSdata.timer$load$port(iors.unit)= 
low(unit$info.baudSrate); 


o utpu t (retSdata. t imer'SloadS po rt (i0 rs.un it) )= 
high(unitSinfo.baudSrate) 
; 


367 
4 
368 
4 


369 
3 
370 
4 
371 
4 


372 
3 
373 
4 
374 
4 
375 
3 
376 
2 
377 
2 


378 
2 
379 
2 


380 
2 


381 
2 
382 
2 


383 


384 
2 


385 
2 


dummySt=rqSr"ceiveSunits( 
/* 
serna */ 
retSdata.intSsema( 
2 * iors.unit), 


/* 
units 
*/ 1, 


/* 
timeSout 
*/ 
0, 


/* status 
*/ 
@exSval); 
i=input (retSctata.usartSdataSport( 
iors.unit 
)); 


goto 
okSsendSresp; 


end: 


/* send 
two 
copies 
of 
the 
detach 
request 
to 
the 
request 
mailbox. 
This 
will 
signal 
to 
two 
of 
the 
I/O 
tasks 
that 
they 
are 
to 


delete 
themselves 
*/ 


call 
rqSsendSmessage( 


/* mbox 
token 
*/ 
retSdata.requestSmboxSt, 


/* 
object 
token 
*/ 
iorsSt, 


/* 
response 
*/ 
retSdata.respSmboxSt, 


/* 
status 
*/ 
t'exSval) ; 


dummySt=rqSreceiveSmessage( 
/* mbox 
token 
*/ 
retSdata.respSmboxSt, 


/* 
timeSlimit 
*/ 
0FFFFH, 


/* 
response 
ptr 
*/ 
t'dummySt, 


/* 
status 
ptr 
*/ 
@exSval); 


call 
rqSsendSmessage( 


/* mbox 
token 
*/ 
retSdata.requestSmboxSt, 


/* object 
token 
*/ 
iorsSt, 


/* 
response 
*/ 
retSdata.respSmboxSt, 


/* 
status 
*/ 
t'exSval); 


dummySt=rqSreceiveSmessage( 
/* mbox 
token 
*/ 
retSdata.respSmboxSt, 


./* 
timeSlimit 
*/ 
0FFFFH, 


/* 
response 
ptr 
*/ 
@dummySt, 


/* 
status 
ptr 
*/ 
@exSval) ; 
goto 
okSsendSresp; 


end; 


do; 
/* case 
6-- 
open 
*/ 


goto 
okSsendSresp; 


end: 


do; 
/* case 
7-- 
close 
*/ 


goto 
okSsendSresp; 


end: 
end; 
/* do 
case 
*/ 


return; 
badSrequest: 


iors.status=IDDR; 
goto 
sendSresp; 


okSsendSresp: 
iors.status=ESOK; 


sendSresp: 
call 
rqSsendSmessage(iors.respSmbox,iors$t,0,@exSval); 
return; 
end; 
/* procedure 
*/ 


cance IS <;34Si0: 
proced ure (ior sS t ,duibS p,retSdataS t) 
publ ic; 


declare 
(iorsSt,retSdataSt) 
token, 


duibSp 
pointer; 


end; 
end 
queue$534$io$module; 
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020CH 
0000H 
0000H 
0038H 
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0D 
0D 
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317 
318 
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32~ 


$nointvector 
Interrupt$534$module: 
do; 


INT$534$TASK 
and 
INT$534$HND: 
PUBLIC 
PROCEDURES: 


This 
module 
contains 
the 
interrupt 
handler 
and 
the 
interrupt 


task 
for 
the 
534 
board 
interrupt. 
The 
handler 
simply 
calls 
signal$interrupt 
and 
the 
task 
reads 
the 
ISR on 
the 
534 


board's 
8259 
and 
sends 
a 
unit 
to one 
of 
eight 
interruptS 


pending 
semaphores 
to 
signal 
the 
occurrence,of 
the 
event. 


$include(: f2:nucprm.ext) 
$SAVE 
NOLIST 


$include( 
:fl:retdta.lit) 


/* 
literal 
declaration 
of 
ret$data 
structure 
for 
init$534$io 
*/ 
$save 
nolist 
$include(:f2:common.lit) 
$SAVE 
NOLIST 


declare 


begin$int$534$data 
byte 
pUblic, 
g$ret$data$p 
pointer'external, 
IO$baseSaddr 
byte 
external, 
int$level 
word 
external; 


declare 


I 
wo rd, 
ex$val 
word; 


l=rq$get$level(@ex$val) 
; 
call 
rq$signal$interrupt(l,@ex$val); 
return; 
end; 


declare 


IO$534$base 
byte, 
int$534$level 
word, 
ret$data$p 
pointer, 
ret$data 
based 
ret$data$p 
structure 
(ret$data$struc) 
, 


c$level 
byte, 
ex$val 
word, 


eoi 
literally 
'2~Ho; 


IO$534$base=IO$base$addr; 
int$534$level=int$level; 
ret$data$p=g$ret$dataSp; 
call 
rq$set$interrupt( 


/* 
level 
*/ 
int$534$level, 


/* 
fl ag s */ 
I, 


/* entry 
point 
*/ 
/* 
data 
segment 
*/ 
/* status 
ptr 
*/ 


interrupt$ptr 
(int$534$hnd) 
, 
~, 
@exSval) ; 


321 
322 
323 
324 
325 
326 
327 
328 


329 


do 
forever; 
call 
rq$wait$interrupt(int$534$leve1,@ex$va1); 
output(IO$534$base+8)=0CH; 
c$leve1=input(IO$534$base+8) 
and 
07H; 


call 
rq$send$units(ret$data.int$sema(c$leve1) 
,1,@ex$va1); 
output(IO$534$base+8)=EOI; 
end; 
/* of 
do 
forever 
*/ 
end; 
/* of 
procedure 
*/ 
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319 
320 
321 


io$534$task$module: 
do; 


This 
task 
receives 
IORS 
segments 
from 
the 
queueSio 
procedure 
and 
performs 
the 
necessary 
input 
or 
output 
operations 
on 
the 
iSBC 
534 
board. 


$ inc 1ude (:f 4:common .1it) 
$SAVE 
NOLIST 


$ incl ude (:f l>pointr .ext) 
/* external 
declaration 
of 
pointerize 
procedure 
*/ 


$save 
nolist 
$ include (:f4:nucprm .ext) 
$SAVE 
NOLIST 
$include{:f4:nerror.lit) 


$SAVE 
NOLIST 


$ inc 1ude (:f 1:retd ta .1it) 
/* literal 
declaration 
of 
ret$data 
structure 
for 
init$534Sio 
*/ 
$save 
nolist 


$include{:fl:iors.lit) 
/* 
literal 
declaration 
for 
iors 
*/ 
$save 
nolist 


declare 


begin$io$task$data 
byte 
public, 
req$mbox$t 
token 
external, 
f$detach$device 
literally 
'5', 
f$read 
literally 
'0', 
f$write 
literally 
'1'; 


declare 


iors$t 
token, 
iors$p 
pointer, 
iors 
based 
iors$p 
IOSrequest$resultSsegment, 
ex$val 
word, 
resp$t 
token, 
buff$p 
pointer, 
buf 
based 
bUff$p 
(I) byte, 
i word, 
unit 
byte, 
ret$data$p 
pointer, 
ret$data 
based 
ret$dataSp 
structure 
(retSdataSstruc) 
, 


c$val 
word; 


do 
forever; 


iorsSt=rq$receive$message{reqSmboxSt,0FFFFH,@resp$t,@ex$val); 


/* check 
for 
non-existence 
of 
mailbox. 
IF last 
device 
has 
been 
detached 


the 
mailbox 
will 
be deleted 
In this 
case, 
delete 
thyself 
*/ 


if exSval= 
ESexlst 
then 


call 
rq$deleteStask(0,@ex$val); 
iorsSp=pointerize{iors$t); 


343 
4 
344 
4 
345 
4 
346 
4 
347 
4 


349 
3 
350 
3 
351 
3 


352 
2 


353 


buffSp=iors.buffSp; 
unit=iors.unit; 
iors.acttJa1=0; 
i=0; 
retSdataSp=iors.auxSp; 


if 
iors.funct 
= 
fSdetachSdevice 
then 
do; 
call 
rqSsendSrnessage( 


/* 
rnbox token 
*/ 
respSt, 


/* 
object 
token 
*/ 
iorsSt, 


/* 
response 
token 
*/ 
0, 


/* 
status 
ptr 
*/ 
@exSva1); 
call 
rqSde1eteStask 
(0,@exSva1); 
end; 


if 
iors.funct= 
fSread 
then 
do 
while 
iors.count 
>0; 
cSva1=rqSreceiveSunits( 


/* 
serna */ 
retSdata.intSserna(2*unit), 


/* 
units 
*/ 
1, 


/* 
time 
*/ 
0FFFFH, 


/* 
status*/ 
@exSva1); 


buf(i)=input(retSdata.usartSdataSport(unit) 
and 
07FH; 


i=i+1; 
iors.count=iors.count-l; 
ior~.actua1=iors.actua1+1; 
end; 


else 
if 
iors.funct= 
fSwrite 
then 


do 
while 
iors.count 
>0; 
cSva1=rqSreceiveSunits( 
/* 
serna */ 
retSdata.intSserna(2*unit+1), 


/* 
units 
*/ 
1, 


/* 
time 
*/ 
0FFFFH, 


/* 
status*/ 
@exSva1); 


output(retSdata.usartSdataSport(unit)=buf(i) 
; 


i=i+1; 
iors.count=iors.count-1; 
iors.actual=iors.actual+1; 


end; 


iors.status=ESOK; 
iors.done=TRUE; 
call 
rqSsendSrnessage(iors~respSrnbox,iorsSt,0,@exSva1); 
end; 
/* 
of 
do 
forever 
*/ 


CODE 
AREA 
SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
624 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


END 
OF 
PL/M-86 
COMPILATION 


fl18DH 
000011 
0001H 
0028H 


397D 
0D 
1D 
40D 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
INIT534HW 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:inithw.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:inithw.plm 
PRINT(:F5:INITHW.LST) 
DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE (4/25/80) 


20 
2 
21 
2 


22 
2 
23 
2 
24 
3 
25 
3 
26 
3 
27 
3 
28 
2 
29 
2 


30 
2 


31 
2 


32 
2 
33 
1 


init$534Shw: 
do; 


This 
procedure 
initializes 
the 
iSBC 
534 hardware 
and 
sets 
up 
the 
device 
dependent 
fields 
of 
the 
retSdata 
segment 
which 
will 
be 
used 
by 
the 
queueSio 
procedures. 


Sinclude(:f4:common.lit) 
SSAVE 
NOLIST 


$include(: f1:retdta.l it) 
/* 
literal 
declaration 
of 
retSdata 
structure 
for 
initS534Sio 
*/ 


$save 
nolist 


declare 


retSdataSp 
pointer, 
retSdata 
based 
retSdataSp 
structure(retSdataSstruc), 


(base,i) 
byte; 


base=retSdata.ioSbase; 
output(base+0FH)=0; 
/* 
board 
reset 
*/ 


output(base+0DH)=0; 
/* 
select 
data 
block 
*/ 


output(base+8)=16H; 
/* 
output 
ICWI 
*/ 


output(base+9)=0; 
/* 
output 
ICW2 
*/ 
output(base+9)=0; 
/* 
output 
mask 
word 
*/ 


/* 
attachSdevice 
calls 
will 
initialize 
usarts 
and 
timers 
*/ 
/* 
set 
up 
tables 
of 
port 
addresses 
for 
use 
by 
queue$io 
procs 
*/ 


ret$data .timer$cmd (0) ,retSdata .timerScmd (3)=36H; 
retSdata.timerScmd(1)=76H; 
ret$data.timerScmd(2)=0B6H; 
do 
i=0 to 
3; 
retSdata.usartScmdSport(i)=base+2*i+l; 
retSdata.usartSdataSport(i)=base+2*i; 
retSdata.timerSloadSport(i)=base+i; 
end; 
retSdata.timerSloadSport(3)=base+4; 
retSdata. t imer Scmd Spo rt (0) , 
retSdata.timerScmdSport(l) 
, 
retSdata.timerScmdSport(2)=base+3; 
retSdata.timerScmdSport(3)=base+7; 
return; 


end; 
end 
initS534Shw; 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


77 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


00E4H 
0000H 
0000H 
0008H 


228D 


0D 
0D 
8D 


APPENDIX B 
Configuration Listings/Worksheets 


FREE 
SPACE 


ROOT 
JOB 


APPLICATION 
JOB 


COMMUNICATIONS 
JOB 


110 SYSTEM 


NUCLEUS 


INTERRUPT 
VECTOR 


Flil: 
LINK86 
& 


:Fl:NUC86.LIB(NENTRY), 
& 


:Fl:NUC86.LIB 
& 
TO 
:Fl:NUCLUS.LNK 
MAP 
PRINT(:Fl:NUCLUS.MPl) 
NAME(NUCLEUS) 


:Flil:LOC86& 
:Fl:NUCLUS.LNK 
TO 
:Fl:NUCLUS 
MAP 
PRINT(:Fl:NUCLUS.MP2) 
SC(3) 
& 
RESERVE(lil TO 
7FFH) 
SEGSIZE(STACK(lil» 
& 


ORDER(CLASSES(CODE,DATA,STACK,MEMORY» 
& 


OBJECTCONTROLS(NOLINES,NOCOMMENTS,NOPUBLICS,NOSYMBOLS) 


i0 s (date, 0 rig in) 
Sample 
I/O 
System 
.csd 
file 
to 
link 
and 
locate 
an 
I/O 
System. 


This 
.csd 
file 
assumes 
the 
I/O 
System 
configuration 
module 
is 
iocnfg.a86 
(found 
on 
the 
release 
diskette). 


The 
origin 
parameter 
sets 
the 
low 
address 
of 
the 
I/O 
System; 
all 
the 
segments 
are 
contiguous 
in memory. 


asm86 
:fl:iocnfg.a86 
date(%0) 
link86 
& 
:fl:ios.lib(ioinit), 
& 
:fl:iocnfg.obj, 
& 
:fl:ios.lib, 
& 
:fl:rpifc.lib 
& 
to 
:fl:ios.lnk 
map 
print(:fl:ios.mpl) 
loc86 
:fl:ios.lnk 
to 
:fl:ios 
map 
sc(3) 
print(:fl:ios.mp2) 
& 
oc(noli,nopl,nocm,nosb) 
& 
order(classes(code,data,stack,memory» 
& 
addresses(classes(eode(%l») 
& 
segsize(staek(0» 


, 
link86 
& 
:fl:ftinit.obj, 
& 
:fl:listen.obj, 
& 
:fl:worker .obj, 
& 
:fl:pointr.obj, 
& 
:fl:rpife.lib 
& 
to 
:fl:apexl.lnk 
map 
print(:fl:apexl.mpl) 
, 
loe86 
:fl:apexl.lnk 
to 
:fl:apexl 
map 
se(3) 
print(:fl:apexl.mp2) 
& 
oe (noli ,nopl ,noem,n"osb) 
& 
order(classes(eode,data,staek,memory» 
& 
addresses(elasses(eode(%l») 
& 
segsize(staek(0» 


, 
link86 
& 
:fl:eminit.obj, 
& 
:fl:eomm.l ib, 
& 
:fl:pointr.obj, 
& 
:fl:rpife.lib 
& 
to 
:fl:eomm.lnk 
map 
print(:fl:apexl.mpl) 
loe86 
:fl:eomm.lnk 
to 
:fl:comm 
map 
se(3) 
print(:fl:eomm.mp2) 
& 
oe(noli,nopl,noem,nosb) 
& 
order(elasses(eode,data,staek,memory» 
& 
addresses(elasses(eode(%l») 
& 
segsize(staek(0» 


fl77EH 
1flE4H 
PUB 
INITDEVICETABLES 
fl77EH 
flFBCH 
PUB 
NAMEDDELETE 
fl77EH 
flEB3H 
PUB 
DECRUSECOUNT 
fl77EH 
flE51H 
PUB 
UNLINKC 
ONN 
fl77EH 
flCA8H 
PUB 
NAMEDCHANGEACCES 
fl77EH 
flB5AH 
PUB 
ATTACHNAMEDFILE 


-S 


-..fl77EH 
fl73EH 
PUB 
ATTACHDEVICETASK 
fl77EH 
fl574H 
PUB 
ILLEGALFUNCT 
fl77EH 
flfl3EH 
PUB 
RQAIOSINITTASK 
fl77EH 
flflfl6H 
PUB 
COPYRIGHT 


SEGMENT 
MAP 


START 
STOP 
LENGTH 
ALIGN 
NAME 
CLASS 


fl77EflH 
1453EH 
CD5FH 
W 
CODE 
CODE 


1454flH 
145FFH 
flflCllH 
W 
REQ TABLE 
CODE 


146flflH 
146DFH 
flflEflH 
W 
lOS-TABLE 
CODE 


~146EflH 
14745H 
flfl66H 
W 
DATA 
DATA 


14746H 
14746H 
flflflflH 
W 
STACK 
STACK 


1475flH 
1475flH 
flflflflH 
G 
??SEG 


--,14750H 
14750H 
flflflflH 
W 
MEMORY 
MEMORY 


Locate Map for 1/0 System 
(The" -." 
indicates entries for job macros and memory map) 


1475H 
e79EH 
PUB 
SETUP544 
1475H 
fl6C5H 
PUB 
PACKETINPUT 


1475H 
fl5B5H 
PUB 
INDEX 
-..1475H 
fl572H 
PUB 
COMMINITTASKENTRY 


-ESS 


SEGMENT 
MAP 


START 
STOP 
LENGTH 
ALIGN 
NAME 
CLASS 


1475flH 
15BCDH 
147DH 
W 
CODE 
CODE 


-.15BDflH 
17flD2H 
15fl2H 
W 
DATA 
DATA 


17flD2H 
1712EH 
flfl4CH 
W 
STACK 
STACK 


1713flH 
1713flH 
flflflflH 
G 
??SEG 
-..1713flH 
1713flH 
flflflflH 
W 
MEMORY 
MEMORY 


Locate Map for Communications 
Job 


17D6H 
fl3B5H 
PUB 
BEGINLISTENERTASKDATA1713H 
fl153H 
PUB 
FOINfERIZE 


-..1713H 
fll12H 
PUB 
INITTASKENTRY 
1713H 
fl4fl1H 
PUB 
WORKERTASK 


SEGMENT 
MAP 


1713flH 
17D6flH 
17E3flH 


17D59H 
1 7E 28H 
17E9AH 


flC29H 
flflC8H 
flfl6AH 


CODE 
DATA 
STACK 


CODE 
DATA 
STACK 


Macro call: 
SYSTEM (system parameters) 


Number of calls required: 
exactly one 


CONFIGURATION FILE NAME 


FORMAT: 


suggested 


- parameter 
~ 
default 
value 
-- 


%SYSTEM 
(nucleus_entry, 
base 
80:0 


rod_size, 
word 
(0) 
..1.ll- 


min_trans_size, 
work 
(64) 
.M.- 


debugger, 
see note 
(A) 
1 
_N__ 


defau It_e_h_provided, 
see note 
(N) 
2 
_N__ 


mode) 
word 
1 


. 


NOTES: 


1. 
Valid entries for the debugger parameter include: 


A 
Debugger available 


N 
No debugger available 


2. 
Valid entries for the default_e_h_provided 
parameter include: 


Y 
Yes 
D 
Debugger 


N 
No 


Macro call: 
SAB (for system address blocks) 


Number of calls required: 
one or more 


CONFIGURATION FILE NAME: 
APEX1 


FORMAT: 


suggested 


parameter 
type 
default 
value 
--- 


%SAB 
(start_base, 
base 
_0__ 


end_base, 
base 
..1.!!QL 
type) 
see note 
U 
1 
U 


. 


NOTES: 


1. 
The type parameter is reserved for future use. Enter 
the character U for this parameter. 


2. 
A SAB is declared between start_base:O and end_base:F, 
inclusive. 


Macro call: 
JOB (defines 
first-level 
jobs) 


Number of calls required: 
one for each first-level 
job 
. 


CONFIGURATION 
FILE NAME: 
APEX 1 


FORMAT: 


suggested 
parameter 
type 
default 
value 
--- 


%JOB 
(directory_size, 
word 
(0) 
0 


pool_min, 
word 
OFFFF 


pool_max, 
word 
(OFFFFH) 
OFFFF 


max_objects, 
word 
FFFF 


max_tasks, 
word 
FFFF 


max_job_priority, 
byte 
129 


exception_hand 
ler_entry, 
addr 
(0:0) 
0:0 


exception_hand 
ler_mode, 
byte 
(1) 
1 
job_flags, 
word 
(0) 
0 


init_tasLpriority, 
byte 
1713:112- 


data.-segment_base, 
base 
(0) 
1706 


stacLpointer, 
addr 
(0:0) 
0:0 


stacLsize, 
word 
(512) 
512 


tasLflags) 
word 
(0) 
0 


NOTE: 


1. 
addr is specified 
as base:offset 


%sab 0',19''''', 
U) 
%job(0,300h,0FFFh,0ffffh,0ffffh,0,0:0,0,0,128,77e:3e,l46e,0:0,S12,0) 
%job(0,lFFH,0FFFH,0FFFFH,0FFFFH,128,0:0,0,0,13l,147S:S72,lSbd,0:0,400,0) 
%job(0,300H,0FFFFH,0FFFFH,0FFFFH,128,0:0,l,0,130,17l3:l12,17d6,0:0,400H,0) 
%system(80,10,64,N,N,l) 


This 
submit 
fsys 
fin 
fout 
con fig 
date 


file 
assembles 
the 
CTABLE 
module, 
where: 
the 
system 
disk 
containing 
ASM86 
the 
source/input 
disk 
(Fl is assumed) 
the 
object/listing/output 
disk 


file 
the 
path-name 
of 
the 
configuration 
file 
the 
date 


copy 
%3 
to 
:fl:config.cnf 
b 


:%0:asm86 
:%l:ctable.a86 
pr (:%2:ctable.lst) 
oj (:%2:ctable.obj) 
date(%4) 
& 
xref 
debug 
ep 


This 
submit 
file 
links 
the 
Root-Job, 
where: 
fsys 
the 
system 
disk 
containing 
LINK86 


fin 
the 
source/input 
disk 
fout 
the 
object/listing/output 
disk 


:%0:link86 
:%l:crooLlib(root),& 


:%2:ctable.obj,& 
:%l:crooLlib 
& 


to 
:%2:rootjb.lnk 
map 
pr(:%2:rootjb.mpl) 


This 
submit 
file 
locates 
the 
Root-Job, 
where: 
fsys 
the 
system 
disk 
containing 
LOCB6 
fin 
= 
source/input 
disk 
fout 
= object/listing/output 
disk 


, 
:%0:loc86 
:%2:rootjb.lnk 
to 
:%2:rootjb 
& 
map 
pr(:%2:rootjb.mp2) 
sc(3) 
& 
name(ROOT 
JOB) 
oc(nocm,noli,nopl,nosb) 
& 
segsize(stack(200h) 
& 
order(classes(data,stack,memory,code») 
& 
addresses(classes(data(12C00H») 


APPLICATION 
NOTE 


System designers are satisfying more and more difficult 
application needs with solutions which use microproces- 
ors in a distributed environment. This distribution of 
intelligence results in many system benefits, including a 
simplification of the design and a resulting decrease in 
the development time of the system solution. An addi- 
tional feature is the minimization 
of the installation 
costs of the system resulting from reduced wiring and 
from resource sharing. However, to effectively create 
distributed solutions, a reliable communication scheme 
must be used which links the various parts of the solu- 
tion together. 


The purpose of this application note is to demonstrate 
the ease with which Intel iSBCTMboards can be config- 
ured to implement distributed 
solutions. 
Several ap- 
proaches are offered which apply standard operating 
modes of both the hardware and of the software. While 
certainly not the only solution, a distributed processor 
communications protocol is developed which will sup- 
port many typical applications. 


Distributed systems generally fall into one of two cate- 
gories. The first consists of those systems in which the 
processors are located in such a manner as to allow com- 
munications over a common system data bus, such as 
Intel's MULTIBUSTMsystem bus. The second category 
involves systems in which the processors are also geo- 
graphically distributed. 
This class of system generally 


uses a form of serial communications to allow each pro- 
cessor to communicate 
with other processors in the 


system. 


The emphasis of this application note is on serial multi- 
processing links. Before proceeding with a development 
of application solutions which involve serial communi- 
cations', this note includes a short discussion of common 
network designs. 


Common Network Designs 


Serial networks may be classed into three general cate- 
gories. These are the LOOP, the MULTIDROP, 
and 


the STAR. Each has applicability to certain iSBC prod- 
ucts and has distinct advantages and disadvantages in an 
application. After discussing the characteristics of each 
network, an application scenario illustrates their uses. 


The loop represents the most common of the communi- 
cation schemes. It is derived from the older teletype 
communication networks in which several printers were 
connected in series. Any data generated on one machine 
causes all machines concerned in the network to echo 
the data. This arrangement is shown in Figure I. Loop 
communications 
normally use a 20-milliamp signal to 


convey the data. The presence of this current, known as 


marking, represents a binary 1 and the absence, or spac- 
ing, of any circuit (an open circuit) represents a binary 
O. Both full and half duplex configurations 
are com- 
monly used. 


The incorporation 
of loop networks into a system im- 


plementation 
creates both advantages 
and disadvan- 
tages. The strongest argument for using a loop is the 
inherent noise immunity which can be gained by using 
the 20-milliamp current to convey the data. The use of a 
high compliance voltage also allows the transmission of 
data for large distances at low to moderate transmission 
rates. 


Solid state circuits common to current technology are 
somewhat less reliable than older mechanical units when 
many stations are configured onto the loop. This is the 
result of the requirement to reproduce the information 
at each node for transmission to the next node. If any 
node fails, all other nodes downstream in the communi- 
cation network will not be capable of communicating. 
Even with this constraint, many good designs incorpo- 
rate the loop network concepts. 


Multidrop networks are fast becoming the accepted net- 
work for multiprocessor communications. 
This type of 


network is shown in Figure 2. As can be seen, this ar- 
rangement is similar to that of the loop. The advantage 
is that all stations are capable of receiving data simulta- 
neously. Multidrop networks are voltage driven since to 
pass current through a node creates a loop situation. 
The electrical interface for multidrop networks consists 
of tri-state drivers and high impedance receivers. The 
RS422 electrical interface is common for this type of 
network since it provides high speed data transmission 
over long distances with good noise immunity. 


The ability to implement networks with a minimum 
amount of hardware and the potential expansion capa- 
bilities provide the multidrop network with a significant 
advantage in many applications. Since each node in the 
network can be added by simply adding another tee net- 
work, expansion is performed 
without the need for 


modification of the communication network. 


Intel's iSBX 35JTMSerial MULTIMODULETM Board is 
an ideal vehicle for the implementation 
of multidrop 


networks. Its use is detailed in subsequent paragraphs of 
this application note. 


Star 
networks 
are 
implemented 
where either 
data 
throughput 
or hardware limitations prohibit the use of 
other types of communication arrangements. 
Figure 3 


illustrates a typical star network implementation. 
Note 


that a star network is really an example of multiple 
point to point communications. 
System throughput 
is 
improved since communication can occur with all slave 
nodes simultaneously 
without the need to have each 


node monitor traffic which is not intended for it. 


Intel's iSBC 544™ Intelligent Communications 
Con- 


troller and the iSBC 534™ Four-Channel Communica- 
tions Board are ideal choices to design star communica- 
tions networks. The outer points of the star are im- 
plemented using any single board computer which has 
on-board 
serial communications. 
An example of this 


type of network is included in this application note. 


Sample Application 


An application example is used in this application note 
to illustrate the techniques which are required to imple- 
ment various types of serial communication networks. 
Both hardware and software aspects of the design are 
described in some detail. 


The application discussed in this note involves the crea- 
tion of an alarm and security system for a multiple 
building complex. This complex is shown in Figure 4. 
The solution generated allows monitoring of three exist- 
ing buildings with provision for the addition of a fourth 
at a later date. The figure shows that each building is to 
have a local annunciator panel for reporting activity in 
those areas served by the building sensors. In addition, a 
main security station provides monitoring of all build- 
ings in the complex. 


PART 
TIME 
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_ 
I 
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Applications such as this are optimized by distributing 
the system intelligence throughout 
the complex. This 


serves two needs; that of minimizing the wiring costs, 
and of providing an improvement in system reliability. 
When a system is distributed in this way, a means must 
be devised which allows communication 
between the 


various elements of the network. Both hardware net- 
work design and software communication protocol are 
required before the system can be considered opera- 


Figure 3. Star Configuration 
tional. 


inter 


In order to illustrate various network designs, the exam- 
ple is broken into a distributed system as shown in Fig- 
ure 5. This is an example of a multidrop communication 
network. The system design does not require that build- 
ing nodes communicate with each other; all communica- 
tions are between building annunciator 
nodes and the 
main operator station. This illustrates the concept of a 
master and a slave. This will be further discussed in a 
later portion of this application note. 


The building annunciator can be further distributed as 
shown in Figure 6. Here, a star communication network 
is created which places data gathering intelligence near 
clusters of sensors. These stations, or nodes, then trans- 
mit information regarding lociil activity to their master 
node, 
the building 
concentrator/annunciator 
panel. 


Note that this panel serves both as a maste~ node for the 
sensor units and as a slave node for the main operator 
station. This arrangement is common in many system 
designs. 


• THE USER 
OF CLUSTER 
SENSOR 
INTEAFACE 
CONCENTRATORS 
MINIMIZES 
WIRING 
COSTS 


• HIGH 
SPEED 
SERIAl 
LINKS 
REPLACE 


MUlTIPtESEHSOR 
WIRING 


• SYSTEM 
INTEGRITY 
IS 
ENHANCED 
BY LOCAL 
DECISION 
MAKING 
AT 
COMMUNICATION 
NODES 


The implementation of communication networks using 
iSBC boards for both star and multidrop techniques is 
detailed 
in the following sections. 
In each case, a 
master/slave 
relationship is assumed. For purposes of 


illustration, actual data from the application example is 
used in performing the sample calculations. While not 


the only possible system designs, those shown are con- 
sidered to be typical and should enable the reader to 
gain an insight into techniques which can be used to 
create similar designs. 


Star Network 
Design 


A star network can use almost any accepted transmis- 
sion media. This is because each node communicates 
with only one other node, creating a multiple point to 
point link. Since the techniques are identical for all 
media, this note discusses only a representative exam- 
ple. RS232C data transmission is used to demonstrate 
the techniques which can be used to establish a star net- 
work. 


The heart of a star network is the master node. It must 
provide a means of independent communication 
with 


each of its slave nodes. Costs can be minimized if multi- 
ple communication 
drivers are placed onto the same 


board. 
The example chosen requires that four slave 


nodes be controlled by the master. The iSBC 544 Intelli- 
gent Communications 
Controller 
provides this func- 


tion. It provides a software selectable baud rate and the 
ability to offload the host processor of communication 
activities. If additional 
slave nodes are required, 
the 


system can be expanded by adding iSBC 544 controller 
boards. 


An ideal choice for a slave node is the iSBC 80/IOBTM 
Single Board Computer. This computer provides good 
processing capabilities with low cost. It includes both an 
RS232C and 20-milliamp current loop communications 
interface. For many small applications it makes an ideal 
choice for a complete single board solution. 


Figure 7 shows the implementation for a four-node plus 
master star communication network for the security ap- 
plication. 
Both the iSBC 544 communications 
board 


and the iSBC 80/IOB Single Board Computer require 
jumpering and component insertion to allow operation 
in either the RS232C mode or in the EIA mode. EIA 
operation 
is electrically identical to RS232C but has 


specifications which allow transmissions at significant 
distances when the baud rate is reduced. For the pur- 
poses of this application note, the terms are used inter- 
changeably. 


=~..o:::=L-"">.""" 
p.=..=-.<=-~ 
=~ 
F=-=-""'-4 


Isec 
lNlfIOB" 
Isec 
.'08" 
Isee 
IOIIOB" 
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SINGLE BOARD 
SINGLE IlOARD 
SINGLE 80ARD 
SINGLE BOARD 
~j~'~ 


ISBCS4<l" 
INTELLIGENT 
CQMM 
BOARD 


inter 


In the case of the iSBC 544 board, a header plug can be 
inserted into an on-board connector to enable the cor- 
rect mode of operation. 
The wiring for this header is 


shown in Figure 8. Note that the ready to send and the 
clear to send signals are jumpered to allow the correct 
operation of the USART without the control signal of a 
modem. Also note that the transmit and receive signals 
are reversed through the header. 


Figure 8. Master to Master Wiring Header. 


The use ·of an RS232C signal for long distance com- 
mu·nication necessitates the use of a low baud rate for 
reliable data transmissions. 
This is shown in Figure 9. 
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The security system application design allows for mini- 
mum communication traffic so a baud rate of 1200 is 
used for the star networks. The placement of intelli- 
gence at the sensor cluster minimizes the amount of data 
which must be transmitted, 
providing 
adequate 
re- 


sponse time at this data rate. 


The hardware design phase includes the selection of the 
communication scheme to be used between the host pro- 
cessor and the slave node. Fortunately, 
this task is 


simplified by the use of built-in master/slave 
protocol 


functions contained on the iSBC 544 communications 
board. These functions involve three hardware features. 
The first is the incorporation 
of dual-ported 
memory 


onto the board. This memory provides a media for the 
storage of data and commands for communication be- 
tween the slave and the host processor. 
The second 


feature generates a flag interrupt 
each time the host 


board writes into the first location of the dual-ported 
memory. The interrupt is cleared when the memory lo- 
cation is read by the slave processor. Finally, the execu- 
tion of the 8085A-2 SOD instruction generates a MUL- 
TIBUS interrupt to inform the host board of the need to 
service the slave. This interrupt can be vectored to the 
host interrupt matrix to activate a service routine in sup- 
port of the slave board. 


A detailed explanation of the use of these features is 
found in another application 
note, AP-53, Using the 


iSBC 544™ Intelligent 
Communications 
Controller. 


The reader should refer to this document for details of 
the board and its use. 
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.mortip 
Network Design 


The complexity of a multinode 
system is minimized 


through the use of a multidrop network. Certain limita- 
tions are placed on the acceptable hardware transmis- 
sion media in multidrop applications. A scheme must be 
used which allows each of the nodes to alternatively gain 
control of the network in order to communicate 
its 


message. 


Both half and full duplex configurations are allowable 
in a multidrop network. While it is simpler from a hard- 
ware standpoint, 
a half duplex connection 
requires 


more stringent communications protocol as this system 
allows communications in only one direction at a time. 
For all practical purposes, no priority for masters or 
slaves is provided. All nodes may listen to whomever is 
using the line at the time. The software must be written 
to allow only one node to communicate 
at a given 


instant. 
An example of a half duplex network is the 


Ethernet. 
More straightforward 
software can be written for full 


duplex communication configurations. 
In this instance, 
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an assumption is made that only one master is config- 
ured into the system and always drives the output lines. 
Any number of slaves can be placed to drive the input 
lines, communicating only when queried by the master 
node. This is the scheme used for the application exam- 
ple which is discussed in this application note. 


Intel's iSBX 351 Serial MULTIMODULE 
Board lends 


itself well to a multidrop application. It allows a wide 
variety of system solutions to be created using any of the 
single board computers 
which incorporate 
iSBX bus 


connectors. Several board options must be enabled to 
create the multidrop communications configuration. 


The first option involves configuring the drivers to use a 
tri-state driver on the output lines. This allows only the 
board desiring to control the communications signals to 
place data on the serial output lines. The board config- 
uration is different for a slave and for a master node. In 
the Intel implementation, 
the driver output signal lines 


are controlled 
using the DTR (data terminal 
ready) 


signal from the USART. The jumper configuration for 
both a slave and a master is shown in Figures 10 and 11. • 
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Figure 
12 illustrates the physical wIfIng data paths 
which are used to create a full duplex multidrop net- 
work having a master and four slave stations. Each 
board must be configured using a header block to pro- 
vide the correct signals. This is done as shown in Figures 
10 and 11. 


Finally, bias resistors are chosen to terminate the serial 
communication data paths. A discussion of the formu- 
las for determining 
the correct values for the two 
resistors is provided in Appendix A of the iSBX 351™ 
Serial MULTIMODULE 
Board Hardware Reference 
Manual (Order Number 9803190). If the equations are 
solved for the componnts used on the RS422 section of 
the board, 
the equations 
for calculating the correct 


values become: 


The drivers used on the iSBX 351 communications 
MULTIMODULE 
board 
limit the number 
of slave 
nodes to 11 for anyone network. If greater numbers of 
nodes are required, 
a driver component 
substitution 
may be required. 


For the example application 
in this note, four slave 
nodes are used, so the calculated resistor values become 
370 ohms for RbI and 205 ohms for Rb2. 


Figure 13 illustrates the acceptable baud rates for vari- 
ous communications cable lengths using the RS422 in- 
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terface. The iSBC 351 board is designed to support data 
transmission rates of up to 19.2 kilobaud. 
Thus, the 
system designed using these boards is seen to permit a 
total multidrop cable length of up to 4000 feet (1.219 
km). The sample application discussed in this note in- 
corporated a total communications link length of 1600 
feet, well within the performance limits. 
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Once the hardware has been defined, the design process 
moves into a software phase. Here, protocols are de- 
fined which provide both data transmission and hand- 
shaking between nodes. 
Handshaking 
is defined 
as 


background communication 
which maintains synchro- 


nization 
and 
integrity 
of the communications 
linl5. 
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Again, standard features of both iSBC board products 
and of iRMXTMsoftware products simplify the incorpo- 
ration of communication protocols into the system solu- 
tion. 


Master/Slave 
Relationships 


In ord.er to maintain an orderly flow of data between 
nodes, software must be created which allocates priority 
and only allows one node to transmit at any instant. The 
most straightforward technique which incorporates this 
function 
is the master/slave 
relationship. 
Here, one 


node is designated as a master and all others are slaves. 
Each slave is allocated a time during which it may trans- 
mit any information to other nodes. The master node 
controls the prioritization of all slave nodes. The com- 
plexity of the system can be further reduced if a full 
duplex scheme is implemented. In this mode, all slaves 
listen only to the master and transmit their messages 
over a common serial channel to the master. A disad- 
vantage of this technique is that direct slave to slave (vir- 
tual channel) transmissions are not permitted. 


Figure 14 shows how a master node establishes time 
slots for windows, during which a slave may control the 
output channel and transmit data to the master. Each 
slave node is assigned a unique identification or address .. 
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Each data packet contains an address as an integral 
part. When a slave recognizes its address in the packet 
from the master, it knows that it has fixed time window 
in which to return its own data packet to the master. 


Communications between each slave and its mas.ter in- 
volve the transmission 
of data packets. Each packet 
contains both handshaking information (such as check- 
sums and message counts) and the information which is 
to pass between nodes. The handshaking portions of the. 
message are used to maintain the integrity of transmis- 
sions in the face of such external stimuli as electrical 
noise. 


Debugging and system maintenance is minimized when 
a means is provided which allows easy viewing and in- 
terpretation 
of 
the 
communication 
messages. 
The 


scheme used in this application note uses a fully ASCII 
compatible communications format. This allows a CRT 
term!nal. to tap onto the link and to monitor all c0pt- 
mum catIOn messages. 


Each message packet begins and ends with a unique 
character. This character cannot exist with a message 
block. Using the ASCII formats, all messages use the 
numeric representation of 0 to 9 and the alpha charac- 
ters from A to Z. A line feed is used to begin a message 
packet and a carriage return is used to terminate the 
message. The assignment of these characters assures an 
easily interpreted message packet. 


The layout of the data packet is shown in Figure 15. The 
justification and description o~ each field is given in the 
following paragraphs. Note that much of the message is 
concerned with maintaining 
system integrity. The re- 


quirement 
for an address field has already been de- 


scribed. Two characters are used for this field and pro- 
vide for 256 addresses (O-FF hex). The protocol being 
described used 0 as the system master and 1through 255 
for possible slave addresses. 
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The next field indicates the type of message being sent 
and the action which is required by the receiver. Anal- 
ysis of system communication 
requirements 
indicate 
that five message types are sufficient. The use of a single 
byte of the packet for this field allows a total of 16 
message types. This leaves II for future expansion. The 
types being used in this application are: 


Type 0 - 
This is a reset request from the master to 


a slave. It will cause the target slave to generate a 
software reset. This command is used only when 
communications cannot be established using other 
means. 


Type 1 - 
A type I command is used to synchro- 


nize the master and the slave. It will cause the 
message counters (see subsequent paragraphs) to 
reset to zero. This command is issued only by the 
master node. 


Type 2 - 
The type 2 message is defined to be that 


which contains information which is to be moved 
between nodes of the communications 
network. 


The exact format of the data is discussed else- 
where. This is the only message which is not con- 
sidered to be of a strictly handshaking nature. 


Type 3 - 
A type 3 message is used to indicate that 


a network node is responsive and ready to handle 
messages. 
When normal 
communications 
have 
been established and no data messages are being 
sent, this message is continuously being sent be- 
tween the master and the slaves. 


Type 5 - 
The final message type is the type 5. It is 
used by the slave to respond to the master's re- 
quest to synchronize. The receipt of this message 
indicates 
that 
the 
slave 
has 
performed 
all 


necessary operations 
with its message counters 


and is ready to receive messages. 


The next field is used to describe the number of mes- 
sages which contain data and have been received or sent 
by each node. The first character is used to indicate the 
number of messages which have been received from the 
master node to that slave. The second character indi- 
cates the number of messages which have been sent 
from the master to the node. Internal software protocol 
enables the communications package to use these fields 
to determine if a data message has been received cor- 
rectly by the target node. If a response message does not 
contain the correct counts, the message can be retrans- 
mitted. Since only one character is used for each count, 
the numbers are allowed to recycle each 15 messages. 


The data field contains information which is to be sent 
to the receiving node. Its exact content is discussed later 
in the application 
note during the discussion of the 


iRMX 80 message extensions. 


A checksum is included to guarantee the integrity of the 
transmitted 
message. 
This 
field contains 
the 
8-bit 


modulo 256 sum of all transmitted ASCII characters, 
beginning with the line feed and continuing through the 
last character of the data field. It is used to compare a 
calculated checksum of received characters 
with that 


transmitted by the sending node. If these two numbers 
are in agreement, the message is considered to be valid 
and can be used by the receiving node's application soft- 
ware. 


The final field is the end of message character. A car- 
riage return is used and provides a unique indicator of 
the end of a message packet. 


The implementation 
of these communication 
concepts 


into a functioning software package is illustrated later 
during the discussion of the layering of the multipro- 
cessing communications package. 


Multitasking 
Message Concepts 


The design of systems which involve distributed 
pro- 


cessors strongly suggests that a multitasking environ- 
ment is also present. The ability to segregate an applica- 
tion into tasks allows a considerable simplification of 
the design and implementation process. In reality, few 
tasks represent 
completely isolated 
functions. 
Some 


degree of communications is required between the tasks. 
This may range from a simple synchronization of tasks 
to a data transfer. Real-time executives simplify these 
processes for the system designer. 
Intel's 
iRMX 80 


nucleus is an excellent example of such an executive. It 
provides low overhead, small physical size, and operates 
on almost all 8-bit Intel single board computers. The 
product has been thoroughly covered in several applica- 
tion notes and it is therefore not necessary to cover it 
again in this note. However, certain features are useful 
for developing a distributed processor extension of the 
basic nucleus. 


An iRMX 80 message is analogous to a letter which is 
mailed to someone. It is sent via a mailroom or post of- 
fice (called an exchange) and is then picked up by the 
receiving party. Each part of the iRMX implementation 
can be thought of in this manner. When a serial com- 
munications 
link is used between the processors, the 


analogy translates to that of sending a mailgram. The 
following short discussion deals with the structure and 
mechanism for sending messages between tasks which 
reside on different single board computers. For clarity, 
the mail analogy is used. 


There are several distinct parts of a message. Each has a 
function and a format within the message structure. 
Before a message can be generated, a medium must be 
procured to contain that message. In terms of a large 
office, this medium is paper; in the multitasking system, 
it is a block of RAM. In order to maintain a continuing 
supply of memory, the iRMX executive provides the 


inter 


user with what is known as a free space manager. The 
purpose of the free space manager is to recycle memory 
blocks so that they can be again used for generation of 
additional messages. This service is called each time the 
sending task requires to generate a message. When the 
communication programs have successfully transmitted 
the message to the target node, the memory block is 
again returned to the free space memory pool. As the 
target node receives the message it must obtain a block 
of memory from its free space manager to store the in- 
formation until it can be processed by the target task. 
The target task returns the block to the pool when it has 
taken the appropriate actions. 


As with any type of message, the individual to whom the 
message is to be delivered must be provided. Because the 
iRMX 80 nucleus is designed to be used by multiple 
tasks on the same processor, the target address mechan- 
ism is not included in the message header itself; instead, 
the target is specified in the call to the iRMX procedure 
as a parameter 
list component. 
When the target ex- 
change address is not known, which happens when mul- 
tiprocessor applications are created, it is necessary to 
create an extension to the executive which allows the 
assignment of a target exchange name to each message. 
Fortunately, this is relatively easy to create. 


iRMX 80™ Named Exchange Extension 


The iRMX 80 nucleus uses a small block of RAM mem- 
ory to store data regarding the characteristics and status 
of each exchange. This storage area normally occupies 
10 bytes of memory. Its layout is shown in Figure 16. 
Except to note that a unique identification field does not 
exist which sets each exchange descriptor apart, 
it is 
beyond the scope of this application note to dwell on the 
meanings of the fields. However, a method must be cre- 
ated which allows the extension of the field to include an 
identification which is unique to that descriptor. 
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Figure 16. Exchange 
Descriptor 


If one is not to rewrite the nucleus, the format of the ex- 
change descriptor must not be changed and the identifi- 
cation field should be added as additional bytes of the 
memory block. Two features of the iRMX 80 nucleus 
make the direct implementation of this concept impossi- 
ble. First, a special exchange descriptor already exists 


within the standard real-time executive. This is the inter- 
rupt exchange which adds 5 bytes to the nucleus for use 
as an interrupt message. Second, if an additional exten- 
sion were to be added, all exchanges would have to be 
created as interrupt exchanges so that common software 
could be used. While this would not in itself be prohibi- 
tive, the interactive configurator 
(ICU 80) does not 


allow addition of fields to either the standard or to the 
interrupt exchange descriptor. 
Another method is re- 


quired to add the extension. 


Fortunately, 
another 
method 
exists to create an ex- 


change. The nucleus operation, 
RQCXCH, 
creates an 


exchange at an address which is specified by a parameter 
of the call instruction. 
If user software is created to 


build the named exchanges, a name can be prefixed to 
each desired name exchange. 


In the standard iRMX 80 nucleus six characters are al- 
lowed to name each task. A logical extension of this 
concept provides a six-character name for each named 
exchange. The exchange descriptor is thus extended by 
inserting 6 bytes before the basic format. In realty, this 
is not sufficient because named exchanges are to be 
created dynamically. The memory blocks representing 
the set of named exchanges to not necessarily constitute 
a contiguous block of RAM. This leads to the creation 
of an additional word of memory to carry a pointer to 
the next named exchange field. A value of zero in this 
field indicates that no additional named exchanges exist. 
If a non-zero value is placed into the field, it is a pointer 
to the next named exchange. Figure 17 illustrates the 
structure of the named exchange fields. 
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The creation of the software to support the named ex- 
change extension is rather straightforward. 
Two func- 
tions are required; one which creates the named ex- 
changes, and a second which will return the address of 
an exchange which matches a given name. A complete 
listing of the software generated to perform these func- 
tions is shown in Appendix A. The services of the free 
space manager are used to allocate the memory seg- 
ments which are used for the exchange descriptors. A 


intel 


quick examination of the program techniques provides 
some insight into the operations involved in creating 
extensions to the standard nucleus. 


Examination of the listing at line 55 shows that a proce- 
dure is used to allow user code to determine the absolute 
address of the iRMX exchange descriptor field from the 
named exchange lists. This address can in turn be used 
with either the RQWAIT or the RQSEND instruction in 
the user's code. If no corresponding name is found in 
the table, a value of zero is returned by the procedure. 
An address parameter is passed in the user call to the 
FIND$EXCH 
subroutine which points to the 6 bytes 
containing the ASCII name of the referenced exchange. 


An internal address value, identified as FIRST$PTR, 
contains the address of the first named exchange de- 
scriptor. A simple DO loop sequence is used to locate a 
matching name in the table lists. Either a zero or the 
location of an actual lO-byte exchange descriptor within 
the extended memory block is returned. 


A task is used to provide the system capability of build- 
ing named exchanges. A task, rather than a procedure, 
is included because a task allows the initialization of 
system pointers such as FIRST$PTR. 
The named ex- 


change building task, 
CREA TE$COM, 
waits at its 
input exchange, COM$CREA TE$EXCH until a request 
for creation of a named exchange is received from a user 
task. The listing for this task is found in Appendix A, 
beginning on line 78. 


When a message is received, the task obtains a 20-byte 
block of memory from the free space manager. It then 
moves the ASCII name from the requesting message 
into the appropriate fields and uses the iRMX primitive 
call, RQCXCH, to create an exchange descriptor within 
the memory block. The pointer field of the last named 
exchange is updated to point to the new memory field 
and the pointer field of the newly created named ex- 
change is set to zero. 


Finally, the address of the actual exchange descriptor is 
returned 
to the requesting 
program 
as an updated 


parameter of the request message. 


The creation of named exchanges greatly enhances the 
capabilities of systems designed around the iRMX 80 
nucleus. This extension allows the generation of distrib- 
uted systems in which tasks may communicate with each 
other regardless of their geographical locations so long 
as some type of link exists. 


Generation of MUltiprocessing Serial 
Communications 
Link 


The creation of software for a serial communications 
link provides the capability of allowing true multitask- 
ing, multiprocessor capabilities. The need for two types 
of communications packages, a slave and a master, indi- 
cates that two separate tasks are required. A compre- 


hensive examination 
of the communication 
require- 


ments indicates that the system can be generated in three 
layers. Figure 18 shows the layer relationships. The first 
is defined as the protocol 
and consists of that code 


which is required to implement the algorithms for either 
the slave or the master network nodes. The second level 
is known as the link level and contains that code which 
is used to support common operations such as message 
generation and data queue handling. The third provides 
a specialized interface to the physical hardware which is 
being used to generate the communications 
link. This 


level, called the physical level, is unique to each con- 
figuration. 


PROTOCOL 
LEVEL COMMUNICATIONS 


PACKAGE 


Two protocol level communications 
packages are in- 


cluded in this application 
note. One implements the 


master protocol and is reproduced in Appendix B. The 
second, the slave protocol, is found in Appendix C. 


No attempt is made to detail the operations which are 
involved in the task generation. The code is commented 
and is readily followed by the reader who has an under- 
standing 
of 
PL/M 
programming 
techniques. 
Some 


facits relating to the implementation of the packages as 
iRMX 80 tasks are in order. 


The master communications package is designed to use 
a USART device which is configured to provide inter- 
rupts at level 7 each time a character is received. A phys- 
ical level interrupt handler supports the receipt of each 
individual character, and, when an end of message char- 
acter (carriage return) is received, places an interrupt 
message into the interrupt exchange, RQL7EX. At this 
point (Appendix B, line 244), the master protocol han- 
dler can begin processing the received message. Because 
the task is associated with interrupt level 7, a task prior- 
ity in the range between 113and 128 must be assigned to 
the task. The example used in this application note uses 
a priority of 113. 


In a similar manner, the slave communications task uses 
interrupt level 6 to receive messages (Appendix C, line 
130). Its priority must lie in the range between 97 and 
112. 


LINK 
LEVEL COMMUNICATIONS 
PACKAGE 


The link level communications package provides a com- 
mon set of procedures which can be used to support 
both the protocol and the physical layers. Listings of 
these support programs are found in Appendix D. The 
programs which make up the package are defined in the 
following discussion. 


Several procedures support the maintenance of the data 
queues. 
These are CQ$Q$INIT, 
CQ$NEXTST AKE, 
and CQ$NEXTSGIVE. The first, CQ$Q$INIT, is used 
to clear space for a data queue. It sets up the length 
parameter and the give and take pointers to their initial 
values. 


Data is placed onto the queue by calling the procedure, 
CQ$NEXTSGIVE, and including the desired data in the 
paramter list. Conversely, CQ$NEXT$T AKE is used to 
take data from the queue. Both maintain the queue 
pointers as data is inserted or removed. For further in- 
formation about data queues, the reader should refer to 
AP-52, Using the iSBC 544™ Intelligent Communica- 
tions Controller. This document contains an extensive 
discussion on the subject of data queues. 


Two procedures deal with the transformation 
of data 


between printable ASCII and the internal binary for- 
mat. CQ$ASC$HEX transfers data from the data queue 
into a working buffer. In the process, it converts the 
format from ASCII into a hex representation usable by 
the target task. Likewise, CQ$HEX$ASC 
is used to 


transform data in a user buffer into a transmittable for- 
mat. In both cases, appropriate 
start and stop charac- 


ters are added or deleted as necessary to create the cor- 
rect format. 


One procedure deals with computing the checksum of a 
message which is in ASCII format. 
This procedure, 
CQ$CHECKSUM, 
returns 
a zero if the checksum 


agrees with that in the message. If an error is indicated, 
a value of - 1 (OFF hex) is returned. 


Finally, two procedures support the generation of mes- 
sage packets. One, CQ$GEN$RDY, is used to build a 
"ready" 
message by creating the appropriate data into 


the fields. The second, CQ$GEN$MSG, 
generates a 


data message containing an iRMX 80 message to be sent 
to an exchange on another processor board. 


The physical level communications 
package provides 


the customization for the unique configuration of host 


processor and USART. Four procedures must be in- 
cluded with this level. These are: 


• 
CQSINIT 
- 
This public procedure 
contains 
all 


operations necessary to initialize the timers, counters 
and USARTs associated with the communications 
code. In addition, this procedure defines the inter- 
rupt service routines for the USART and enables the 
corresponding interrupt levels. 


• 
CQSSTARTSMSG 
- 
A public procedure 
which 


places the USART into a mode in which the transmit- 
ter is enabled. The execution of this procedure should 
result in an interrupt being generated by the USART 
transmitter ready line. 


• 
CQMIVT 
- 
This is an interrupt service routine asso- 
ciated with the USART receiver ready line. It is en- 
tered each time that a character has been received by 
the communication node. In the case of a slave node, 
this procedure is known as CQSIVT. The name is 
unimportant 
because the location of the routine is 


passed to the iRMX 80 nucleus at initialization by the 
CQ$INIT program. When a carriage return (end of 
message) is encountered, a message is passed to the 
protocol level task by passing a message to the inter- 
rupt exchange, RQL6EX, using the iRMX primitive, 
RQISND. 


• 
SENDSCHAR 
- 
Like the CQMIT routine, this is 


an interrupt 
handler procedure. 
It is entered each 


time the USART signals that it is ready to transmit a 
character. A new character is obtained from the data 
queue and it is transmitted to the receiving node. If 
the character is the end of message, flags are set and 
the USART transmitter is disabled. 


The listing of a sample physical driver is provided in Ap- 
pendix E. This driver illustrates the use of the iSBX 351 
Serial MULTIMODULE Board placed into a socket of 
an iSBC 80/24 Single Board Computer. 


The example from the application implements a multi- 
drop slave node. The enabling of the tri-state drivers is 
accomplished in line 138 by sending the USART a com- 
mand of 025H. When the message has been sent, the 
driver is again placed into a high impedance mode by 
sending a command of 026H (line 121). These com- 
mands control the driver by toggling the DTR or Data 
Terminal Ready lines of the 8251A USART device. 


The alarm and security system previously discussed pro- 
vides a perfect environment in which to use the concepts 
developed in this application note. 


To verify the functionality of the communications pack- 
age, the transmissions 
between a master and a slave 
were monitored using a CRT terminal. The terminal was 


inter 


connected to one of the RS232 serial paths using a tee 
network. This tee network is shown in Figure 19. Sev- 
eral scenarios were set up to test the effectiveness of the 
communications protocol. The results of some of these 
tests are recorded in the following discussion. 


A test of normal communications 
was performed 
in 
which one message is passed between the master and the 
slave. A short time later, a message is passed to the 
master from the slave. The CRT display for this action 
displayed as: 


(line 1) 
033ססoo 
(line 2) 
00300FD 
(line 3) 
03200091230900BFOOOOOOOO9F 


(line 4) 
00310FE 


(line 5) 
0331001 


(line 6) 
002108247090087000000008A 
(line 7) 
0331102 


(line 8) 
00311FF 


Line 1 is a "ready" 
(character 3) message from the 
master node to a slave addressed 03 hex (characters 1 
and 2). No messages have been sent in either direction at 
the time this message was generated. On line 2, the slave 
has responded indicating that it is present and ready to 
receive messages. It also has not transmitted any mes- 
sages to the master nor has it received any. 


The master node sends the slave a message on line 3. 
Note that the message count field (characters 4 and 5) is 


~ 


VCl 


1 
2 
+9 
Vec 


13 
3 


-9~ 
14 
~ 


@YI 
VEE 


not changed until after the message has been trans- 
mitted. The message sent is a type BF and has a total 
length of 9 bytes. On line 4, the slave acknowledges that 
is has received one message and has sent none. 


Lines 5, 6, and 7 illustrate a sequence in which the slave 
sends a message to the master node. Prior to the mes- 
sage being sent, the message count field shows that one 
message has been received. After receiving the message, 
the master node increments its received counter. 


Tests with the alarm and security system verify that the 
communication module functions correctly. Data integ- 
rity is maintained even through intentional disruption of 
the electrical link. Both the RS232 and RS422 communi- 
cation paths function as designed. 


A detailed discussion of this application 
and of the 


multitasking capabilities of the iRMX 80 nucleus can be 
found in AP-112, Simplifying Complex Designs Using 
The iRMX 80™ Executive. 


This application note illustrates the ease with which a 
user can add extensions to the iRMX 80 executive to 
support 
a distributed 
multiprocessing 
application. 
In 


addition, the user of standard 
"off the shelf" single 


board computers and expansion modules to create a 
hardware solution is explained. 


The abilit-yto break applications into small tasks, either 
functionally or geographically, aids the system designer 
by allowing his concentration on each task. A message 
transfer capability allows these tasks to again be tied 
together to form a complete solution to the application. 
Where the tasks reside on the same single board com- 
puter, the standard iRMX nucleus provides this ability. 
When different host boards are used, extensions to the 
nucleus allow the same functions to be performed. Both 
multiple processors on the same MULTIBUS chassis 
(refer to AP-88 and AP-lJ 2) and in different chassis 
using the serial links described in this application note 
can be supported with extensions to the nucleus. 


Many concepts are used to create serial communication 
networks. 
Intel's 
single 
board 
computer 
products 
simplify the de~ign process. Among these products, 
several stand out in this application. For example: 


• 
iRMX 80™ Executive 
- 
This outstanding product 


simplifies the design of multitasking systems and pro- 
vides a foundation for the implementation of exten- 
sions to create many varied configurations. 
Such 


things as task synchronization, 
interrupt 
handling, 
and message transfers allow multitasking. 
The free 
space manager allocates RAM and is an integral part 
of the serial communicaitons link software. The ter- 
minal handler and the disk operating system simplify 
the software design by providing ready to use I/O 
drives which can be accessed by the user. 


• 
iSBC 
80/10BTM Single 
Board Computer 
- 
This 
microcomputer 
allows a low cost solution to many 
small to medium applications. The ability to operate 
the board in an iRMX 80 environment enhances its 
capabilities by allowing it to multiprocess. 
Its on- 


board serial communications link allows it to be used 
as a slave node in either EIA or current loop com- 
munications networks. The iSBX MULTIMODULE 
connector further enhances its capabilities by allow- 
ing customization of I/O to meet a wide variety of 
user applications. 


• 
iSBC 
544™ Intelligent 
Communications 
Board 


- 
The use of this board allows much of the protocol 


and physical drivers to be off-loaded from the host 
processor. The board provides an ideal master com- 
municatons node for star type networks. By placing 
the handshaking 
operations on the communication 


board, 
the 
host 
is free to perform 
application- 


oriented functions with a much higher throughput 
rate. 


• 
iSBC 
80/24™ 
Single 
Board 
Computer 
- 
This 


powerful 8085A-2 based microcomputer 
board pro- 
vides the capability to implement most of the system 
functions without the need to expand to additional 
memory or I/O expansion MULTIBUS boards. 
It 
fully supports the iRMX 80 executive. Its ability to 
act as a full bus master allows even greater flexibility 
through the implementation 
of MULTIBUS multi- 


processor solutions. 
The two iSBX MULTIMOD- 


ULE expansion connectors 
provide the user with 
considerable flexibility in the design of his system. 
The use of one of these sockets as a carrier for the 
serial 
communications 
MUL TIMODULE 
board 


makes a multidrop serial communications link prac- 
tical. 


• 
iSBX 351™ Serial 
MULTIMODULE 
Board - 
The 


implementation 
of multidrop 
communications 
re- 


quires the use of an electrical interface which sup- 
ports more than one communicaitons 
node to share 


the link. The use of the RS422 operating mode of the 
board easily implements this feature. A well-defined 
hardware protocol also assists in the implementation 
of a serial multidrop communications link. Up to 11 
slave nodes can be designed into a system using this 
powerful board. In addition, the iSBX 351 board can 
function in either the RS232C or the EIA mode for 
linking into terminals or for creating a point to point 
network. 


The assistance of Judy McMillan in the implementation 
and testing of the security system and its communica- 
tion links is greatly appreciated. 
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inter 


26 . 
27 


$title('RMX/80 
EXTENSION 
TO NAME 
EXCHANGES, 
VERSION 
1.3') 


createScom$exch: 
do; 


/********************************************************* 
CREAT$EXCHANGE 
creates 
a list of exchanges 
associating 


the 
name 
of an exchange 
with 
its location, 
for 
the purpose 


of other 
tasks 
wishing 
to find 
the 
loc~tion 
of an exchange. 


FIND$EXCHANGE, 
when 
given 
the name 
of ~n exchange, 
polls 
down 
the 
list and, 
when 
it finds 
a match, 
returns 
the 
address 
to the 
requesting 
task. 
/********************************************************* 
$nolist 


declare 
COMSCREATESEXCH 
exchange$descriptor 
public; 


declare 
CREATE$EXCH 
exchangeSdescriptor 
public; 


declare 
first$ptr 
declare 
last$ptr 
declare 
msgSptr 


declare 
exch$ptr 


declare 
n 


address; 
address; 
eddress; 
address; 
byte; 


declace 
request 
based 
msg$ptr 
structure( 


msgShdr, 
exch$name(6) 
byte); 


declare 
fs$req 
structure( 


msg$hd r, 
msg$length 
address); 


declare 
exch 
based 
exch$ptr 
structure( 


name(6) 
byte, 


exchange(l~) 
byte, 


link 
address); 


declare 
lastSexch 
based 
lastSptr 
structure( 
name(6) 
byte, 


exchange(lO) 
byte, 
link 
address); 


declare 
response 
based 
msgSptr 
structure 
( 


msg$hd r, 
exchange 
address 
); 


NAMEX: 
Procedure(exptr) 
address 
public; 
,eclare 
addr 
address; 


declare 
exptr 
address; 


declare 
(ex based 
exptr) 
(6) byte; 


inter 


11 t 
;:> 


.-: ~ 
.., 
" 


116 
;:> 
47 
2 
L!P 
2 
L!S 
2 


Sf: 
;:> 


Sl 
;:> 


52 
;:> 


5t; 
'2 
57 
2 
Sf' 
2 


5~ 
2 


(;} 
2 
h2 
:: 
t:;2 
:: 
r.;t, 
~ 
rs 
<1 


r,~ 
5 


~~clar~ 
retSMs~ 
h?sed 
addr 
structure(msqhdr, 
exchS?dr 
ed~ress); 


~eclpre 
reg 
structure(msgShdr, 
ni"me((,) byte); 


/* cre2te 
pn 
e~ch2nge 
to 
communicate 
with 
tI'e COMr.1,re?te 
exchangf' */ 


dec12re 
fsx 
exchpngedescriptor; 
cell· rqcxcr(.fsx); 


reo.length 
= 
]~; 
cpl] 
noveU>, 
.ex, 
.req.name); 
reg.type 
= 
2r.r.; 
reg.responseSexchange 
= 
.fsx; 
cpll 
rosend(.coMcreateSexch, 
.reo); 
;1c1c1r rqw?it(.fsx,0); 
?der 
= 
retSnsg.~xchSadr; 


return (i1(le 
r); 
end; 


FINDSEXCf-1: 
proceeure 
(n?MeSptr) 
address 
public; 


/****<************************************************* 
it-·i;• ro,e(~ure 
finc:s the 
exch?nge 
hpving 
e nemc 
specified 


by 
the 
passed 
ppremeter 
pointer. 
If? 
metch 
is 
foune 
the 


exchange 
pddress 
is 
returnee. 
If no 
match 
is 
found, 
2 


zero 
is 
returner. 
********************************************************/ 


declere 
n?meSptr 
eeeress; 


declare 
rn?tch byte; 


cecl?re 
(naIT'eb2.sed n2.rnpSptr)«(,) 
byte; 


/* tpst 
for 
no 
exchanges 
*/ 


if 
firstSptr 
= r 


then 
return 
0; 


/* test 
for 
c nprne match 
*/ 


else 
(lo; 
excrSptr 
= 
firstSptr; 
do 
vln i leI 
; 
MAtch 
= 
C'ffr; 


('0 
n = r 
to 
5; 
if 
n?me(n) 
<> 
exch.nAMe(n) 


inter 


fit' 
5 
(,S 
.1 
71 
4 
73 
~ 
74 
.1 
75 
3 
7" 
;> 
77 
2 


7? 


79 
;> 
8e 
2 


81 
2 
82 
2 


83 
2 


84 
3 


P5 
3 
er. 
3 
e7 
3 
8f' 
3 
89 
3 
9C 
3 
91 
3 


92 
3 


end; 
if 
Match 
then 
return 
.exch.exch~nge; 


if 
exch.link 
= 
r. then 
return 
r; 


exchSptr 
= 
exch.link; 
end; 


enc; 


return 
0,; 


enc; 


CRE.aTF.SCO/'ll: 
procedure 
public; 


/********************************************************* 
This 
procedure 
creates 
exchange 
extensions 
when 
askec 
to 
do 
so 
by 
a 
task 
that 
wants 
its 
exch~nge 
made 
completely 


accessible. 
It 
saves 
the 
name 
of 
the 
exch~nge 
then 


creates 
an 
exchange 
to 
save 
its 
aeeress. 
It may 
he 
urdated 
at 
any 
time. 
. 


****************~*****************************************/ 


/* 
initialize 
exchanges 
*/ 


call 
rqcxch(.com~create$exch); 


call 
rqcxch (.create~exch) 
; 


/* initialize 
pointers 
*/ 


last~ptr 
= 
0; 


firstSptr 
= 
0; 


/* get 
a 
request 
for 
creation 
of 
an 
exchange 
*/ 


msg~ptr 
= 
rawait(.com$createSexcr., 
r); 


/* get 
some 
memory 
for 
the 
excr.ange 
*/ 


fsSreo.length 
= 
11; 
fsSreq.type 
5; 
fs$req.response$exchange 
= 
.creat0$excr.; 


fsSrea.msgSlength 
= 
?0; 
call 
rasenr(.rqfsax, 
.fs~rea); 
exch$ptr 
rqwait(.createSexch, 
r); 


exchSptr 
= 
fsSreq.msg~length; 


/* store 
name 
in 
the 
exchange 
structure. 
*/ 


call 
mover 
", 
.request.exchSni'me(0), 
.exch.nAme!"» 
; 


/* create 
en 
exchange 
*/ 
CAll 
rqcxch(.exch.exchan0e(r»; 


if 
IC'stSptr 
> 
0 


then 
co; 
last$exeh.link 


::7 
11 


91' 
t. 


9S 
11 


Irr 
3 
lCl 
£1 


Ir2 
/I 


Jr3 
<1 


1(''1 
4 


H: 
3 
1('5 
3 


In 
3 


lC8 
:2 


H9 
] 
ene' ; 
end; 


~ODULE 
INFOR~ATICN: 


CODE 
/lRE)\ 
SIZE 


V/lRIJlPLE 
l'REJI SJzr 


MAXIMUM 
ST/ICK 
8J7E 


244 
LINES 
liE'.!:' 
o 
PRCGRA~ 
ERROR(S) 


lastSptr 
= 
exchSptr; 
excr.link 
= r; 
eno; 
else 
co; 
C'xch.link 
= 
P; 
, 


firstSptr 
= 
exchSptr; 
l~stSptr 
= 
exch$ptr; 


/* return 
the 
exchange 
pointer 
*/ 
response.exchange 
= 
.exch.exchan?e; 
call 
rqsend(reauest.responseSexchange, 
msgSptr); 


CJID3H 
nr4?H 
{'(1r"H 


L\G7D 
72D 
4[' 


~:tit 1(' ( , ~.'" stP.rC 
0 Tnm un iC7Clt i.0 ns Pro to co! r r ive r, Ve rs ion 
p.]') 
1 
~~~TF.R~r.r,JVF.R:00; 
/* 
Tre 
tc>sk C7ont?ineo 
in 
thi.s listing 
supports 
the 
f!l?ster 


C7omnunic2tions 
protocol 
for 
extabJishins 
network 
conTnun- 


ic?tions. 


The 
tAsk 
must 
re 
confi(lure(l using 
the 
TCU/pr 
2S 
follov's: 
T~S~ 
N~~F.: MISTER 
TASK 
H'TRY 
POItlT: ~1LTNY 
TASK 
pnIORITY: 
1J3 
Tr'f'K STICK 
LENGTH: 
1rr 


EX01"NGE: 
POL 7FX 
SCOPF.: 
FXTF.RI\'AL 
INTERRl'PT: 
YFS 
EXCHI'·NGF.:TIr-'EX 
SCOPE: 
PUBLIC 
INTERRUPT: 
NO 


LTNK: 
LIt~K : 
: Fn: 
CC'CO~~. LIF 
:Fn:C(1Rf'LV.LIP 


T2.sks 0esiring 
to 
senr 
? ~essClge 
to 
2. norP 
shoulr 


spn~ 
? Mess?Op 
to 
the 
eXC7r?nge 
Cr~IFX(no~e). 


*/ 
Sir..luce 
(:fr:exch.eltl 
rr~··~E 
F.XCPANCE~DFSCRIPT(1R 
LITf.R"LLY 
I STRl'CTURF 
( 


Mf'G~HEAn 
~DnRFSS, 
~SG~TI'IL 
ADDPErS, 
TISK~HEAD 
ADDRF.f'S, 
Tlf'KST1IL 
ADDRESS, 


NEXTSEXCP 
lDDRESS) 
'; 
tinclucJe 
(:fr:ier.clt) 
DECL"RE 
INTSEXCHANGEtDFfCRIPTOR 
LITER~LLY 
'STRUCTURE 
( 


MESSI'CF.$PEAP 
lDCRFSS, 
MESS"CE~TAIL 
ADDRESS, 
TASKSHEI'D 
"DDFESS, 
TASKSTAIL 
I'DrPESS, 
EXCHANGEtLINK 
ADDRESS, 
LH'K 
.ADDRFSS, 
LE!,TGTH ArDRESS, 
TYPE 
PYTEl '; 
Sinclude 
(:fr:rnsq.eltl 
DECLARE 
MSG$HDR 
LITERALLY 
I 


inter 


1 
1 
= 
1 
1 


LINK 
ADDRESS, 
LENGTH 
ADDRESS, 
TYPE 
BYTE, 


HOME$EXCHANGE 
ADDRESS, 
RESPONSE$EXCHANGE 
ADDRESS'; 


DECLARE 
~SG$DESCRIPTOR 
LITERALLY 
'STRUCTURE ( 


MSG$HDR, 
REMAINDER (1) BYTE) '; 


$inciude 
(:f0:common.eIt) 


DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARf: I'ALSE LITER.A.LLY'00H'; 
DECLARE 
BOOLEAN 
LITERALLY 
'BYTE'; 


DECLARE 
FOREVER 
LITERALLY 
'WHILE 
1'; 


$include 
(:f0:synch.ext) 
RQSEND: 


PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,~ESSAGE$POINTER) 
ADDRESS; 


RQWAIT: 


PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS; 


RQACPT: 


PROCEDURE 
(EXCHANGE$POINTER) 
ADDRESS 
EXTERNAL; 


DECLARE 
EXCHANGE$POINTER 
ADDRESS; 


RQISND: 


PROCEDURE 
(IED$PTR) 
EXTERNAL; 
DECLARE 
IED$PTR 
ADDRESS; 


END RQISND; 


$incluJP 
(:f0:intrpLext) 


RQENDI: 


PROCEDURE 
EXTERNAL; 


RQELVL: 


PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 


RQDLVL: 


PROCEDURE 
(LEVEL) EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 


~'. 
-< 
~, 
2 
_ 
J. 


32 
'2 


33 
2 


31' 
.1 


35 
2 


]r; 
2 


37 
'2 


3f. 
1 


39 
1 


4r 
1 


il ] 
1 


t.I' 


45 
2 


ilr; 
2 


47 
1 


il!.' 
2 


119 
2 


50 
1 


51 
'2 


"" 
'2 
_ 
L. 


RQSETV: 
PROCEDURE 
IPR8C,LEVEL) 
FXTERN~L; 
DECLlhE 
PRO~ 
ADDRESS; 
PE~LIPE 
LEVEL 
RYTE; 


ROSETP: 
PRCCFCVRE 
IPRCC,LEVFL) 
EXTERNAL; 
DECLARE 
PROC 
~DDRESS; 
CECL~RE 
LEVEL 
EYTE; 


H!D 
RC'SFTP; 
Sincluce 
(:fr:fsll'lJr.f'xt.) 
DECLIRE 
RQFS~X 
EXCHANGESDESCRIPTCR 
EXTEP.NIL; 


DECLARE 
RQFSRX 
EXCHINGESDESCRIPTOR 
EXTERNAL; 
DErLAPE 
RQFREE 
FXCHANGESDESCRIPTOR 
EXTERNAL; 


Sincluc'e 
{:fl:m2smsg.elt) 
cpclere 
msgSformet 
literally 
'structure 
( 


trgt. 
byte, 
crmd 
byte, 
seqSl<" 
byte, 
scqSn2 
byt.e, 
text(25C1) 
byte) 
'; 


declare 
queueSformct 
liter2l1y 
'structure 
( 


encSptr 
byte, 
giveSptr 
byte, 
takeSptr 
byte, 
0c.t.aSbyte(251l) 
byte)'; 


ceclrre 
FrrSfor~?t 
literc.lly 
'structure 
I 


ne 
byte, 
J? 
byte, 
run 
byt e, 
stop 
bytP, 
queSpt 
byt.e) 
,; 


Sinclude 
(:fr.:objm?n.ext) 


ROCTSK: 
PRCCEDURE 
(STATICSFTR) 
EXTERNAL; 


DFrLIRF 
STATICSPTR 
IDrPE~S; 


RCCXCH: 
PROCEDURE 
(EXCH'NGESPTR) 
EXTERNAL; 
DECL~RE 
EXCHINCE$PTR 
rDDRESS; 


END 
RQCXCH; 


SincJude 
(:f] :co~co!T1.e)(t) 


C('SNEXTSGIVE: 
Procec'ure 
(aSpt.r,<::iveSbyte) byte' extern?]; 


Declrre 
qSptr 
?ddress; 


Declare 
givf'Sbytf' byte; 


inter 


53 
2 
511 
1 


:5 
2 


5(; 
'} 


57 
1 


5f' 
2 


59 
'} 


r.;r 
1 


G1 
2 


1)2 
2 
t;] 
'2 
hi! 
1 


h5 
2 
(in 
2 


F,7 
1 


(;e 
2 
(,9 
2 
70 
1 


71 
2 


72 
:? 


7: 
') 


711 
1 


75 
'2 


7F. 
'2 


77 
:? 
7P 
1 


7S 
2 
8C 
2 
1'1 
2 
£'2 
1 


83 
2 
8;' 
'2 
85 
2 


[I) 
1 


P7 
'} 


88 
1 


p~ 
2 


SI() 
:? 
91 
1 


92 
'} 
~3 
2 


en~ 
cq~next$give; 


CC'STJlYESTFST: 


Pr0cedure 
(q$ptr) 
byte 
externi'l; 


D~cli're 
c.~ptr i'ccress; 


enc 
cqStekeStest; 


CQSNEXTSTlIKE: 
Pr0cedure 
(q$ptr) 
tyte 
externel; 


reclere 
q$ptr 
~cdress; 


end 
cqSnextSteke; 


CQS0$TNIT: 
Pr0ccdure 
(q$ptr,q$size) 
extern.;>l; 
reclere 
q$ptr 
ad~ress; 
Declare 
q~size 
byte; 


enc 
cq$qSinit; 


CC'S"SCSBF.X: 
Proce(~ure 
(q$pt r,1'1sg~ptr) externC' I; 


Declare 
(q~ptr,msgSptr) 
a0.cress; 


end 
cq$escShex; 


CQSCf)ECKSU~' : 
Procedure 
(qSptr) 
hyte 
external; 
recl?re 
qSptr 
address; 
enr 
cqSchecksuln; 


CQSHF.X$]ISC: 
Procecure 
(qSpt r,rexSbyt(') 
external; 


Declare 
qSptr 
acdress; 


DecJare 
hex$byte 
byte; 


enr 
cqSrexSesc; 


CQStJlSGSOUT: 
Procedure 
(msgSsize,aSptr,pi'rSrtr,ms~Srtr) 
external; 


reclere 
msgSsize 
byte; 


Decl'"re 
(q$ptr, pa rSpt r ,msgSpt r) address; 
enr 
c-qSfT'!sgSout; 


C0SGENSRDY: 


Pr0ceciure 
(trget,l"sgSptr,(!Sptr,pi;r~ptr) 
externC'l; 
Declare 
trget 
byte; 


Declc>re 
(msgSptr,qSptr,perSptr) 
a~cress; 


enc 
c-aSCJen~rdy; 


CC$CE?-'$tJlSG: 
Procedure 
(msgSpointer,trget,nsgtptr,qSptr, 


pi'rSptr,si'veSflg) 
externi'l; 
Dcclere 
(trget,sClve$flg) 
byte; 


Declare 
(msgSpointer,nsgSptr,qSptr,parSptr) 
?r.c'ress; 


enc 
ca$genSmsg; 


U~RINT: 


Procedure 
external; 


f'n~ usrint; 


FJNDSEXCH: 
ProcedureCnemeSptr) 
ecdress 
externi'l; 


ceclare 
n<'met-ptr rcdress; 


end 
find$exch; 


/l1.aMEX: 
Procecure(exptr) 
rddress 
external; 


oeclare 
exptr 
aacress; 
enr. ni'JTlex; 


HI 
lr7 
H:? 
Hi' 
H5 


return~rel'l: 
procp(!ure (pointer) 
ext.f'rn2]; 


declere 
pointer 
?dcress; 


end 
ret.urnS ral'l; 


CertAin 
liter2ls 
are 
used 
tu 
opfine 
the 
network's 
physic2l 
cherectpristics. 
These 
ere: 


Declere 
N~N0DE 
liter?lly 
'~'; 
/* number 
of 
nofes 
*/ 
rc-clare 
NrDFSPPRAY 
liter~lly 
IS'; 


~ structure 
provides 
the 
fete 
aueues 
for 
the 
trens~ission 
of 
oate 
tu 
f'?cr noee. 
It 
is cefineo 
ene 
is aveileble 
?s 
a public 


A 
single 
cet.e 
queue 
is 
used 
to 
support 
the 
input 
of 
dete 
frun 
a 
nooe 
since 
unly 
une 
sIeve 
is given 
e 
window 
et 
? 
ti~e: 


Each 
node 
has 
an 
associeted 
set 
of 
flags 
which 
indicete 
ihe 
operation?l 
noee 
of 
that 
node. 
The 


function 
of 
eech 
bit 
is eefinee 
?s: 
bit 
\I 
- 
reouest 
synchroniz?tion 
(synch~request) 


bit 
1 
request 
initi?lizr.tion 
(init.Srequest) 


bit 
2 
repeet 
lest 
nf's~ege 
(repeQtSreouest) 


bit 
3 
bit 
4 


bit 
5 
bit 
r:; 


bit 
7 - error 
fleg 
(errorSflaCT) 


Declere 
CCC~DF(noee~err?y) 
hyte 
public; 
Declare 
SYNCHSREQUEST 
literally 
'rlH'; 


Ceclere 
INTTSPEOUEST 
liter?lly 
'r2H'; 


Declere 
REPE~TSREOUEST 
literelly 
'r~r'; 
Decl?re 
ERRORSFLAC 
literelly 
'PCB'; 


r 
counter 
is 
usee 
to 
indicate 
the 
number 
of 
?ttempts 


to 
estab'J.,ishcOl'lmunicetions 
wi th 
e 
node. 
Vhen 
it 


re?c~es 
a n?xiJT1um v?lue, 
? synch 
will 
te 
sent 
to 
the 


nude. 
when 
the 
maxinum 
v?lue 
of 
synchs 
ere 
sent 
to 
a 


nude 
vith 
no 
effect, 
2' 
reset 
will 
he 
sent 
to 
the 
node. 


inter 


] 12 
] 


11:.' 
1 


] ] 4 
1 
115 
1 
11r; 
] 


117 
] 


lIP 
] 


lJ9 
1 


] 2r 
1 


12] 
1 


122 
1 


]23 
] 2 L' 


Declare 
E~RO~~COUNT(noce~erray) 
byte; 
Cec1?re 
~]I.X~CClJNT liter?lly 
'5'; 
reclere 
SYNCB~COUNT(nocetprr?y) 
hyte; 


/* 
a 
pointer 
is 
usee 
to 
store 
the 
pedress 
of 
exch?nges 


usec 
hyincornminq 
messages*/ 


]I set 
of 
exch?noes 
is 
usee 
to 
holc 
? 
~ess?ae 
until 
it 


h?s 
been 
pcknowlec0ec 
by 
the 
slave. 


]I set 
of 
exchanges 
is 
providec 
to 
accept 
messages 
which 


are 
to 
be 
sent 
to 
any 
of 
the 
nodes. 


Declare 
reqSmsg 
structure 
msgShcr, 
Msg$length 
aeeress 
); 


Declare 
(m,n,nodetcnt,outmode,raJT1Ssize) 
byte; 
Declare 
~sgsptr 
acoress; 
Declare 
msg 
msgSformat; 
declare 
st?rtt5l'4 
byte 
public 
?t 
(PrcH~h); 


Declare 
dat?Sblock 
baseo 
msgtptr 
structure 
msgShcr) 
; 
Declare 
CQ~PJlR(noceS?rr?y) 
rar~for~at 
puhlic 


at 
(PO('2h); 
Ccclare 
RA~S~SG 
b?sed 
msgSptr 
structure 
( 
msgShcr); 
Cecl?re 
CQSPCTIVESNODE 
byte 
public 
at 
(perlh); 
Ceclare 
freSmem 
ac~ress; 


Declare 
freSmsg 
hasec 
freSmem 
structurc(msgSrrr); 


The 
task 
uses 
certain 
exchanges 
for 
intern?l 


cOJT1munic?tions 


Declare 
CQM~EX 
€xch?ngeScescriptor; 
Declare 
RQL7EX 
intSexch?ongeScescriptor 
public;. 


Seject 
/******************************************************* 


e r rorSt.est 
This 
short 
proceeure 
is 
used 
to 
increment 
the 
error 


counters 
ano 
to 
signal 
an 
initi~lization 
or 
synch 
comm?nd 


when 
reauired. 
It 
will 
oreer 
a 
re-transmission 
of 
the 


last 
message 
e?Cr 
time 
?on error 
is 
oetectec. 


125 
1 


12" 
2 


In 
3 
129 
3 


131 
l! 
132 
11 


133 
~ 
13<1 
3 


1 .,t: 
3 
--- 
]2(, 
2 
137 
2 
13P 
2 


13~ 
1 


ll!r 
2 
141 
3 
1"2 
3 
10 
3 
144 
3 
1~5 
3 


1-1~ 
2 


10 
2 
11l£ 
3 
1l!C; 
3 
150 
3 


151 
2 


157 
') 


153 
2 


If 
(error~count(n) 
:=error$count(n)+l) 
> m;ox~count 


then 
00; 
prrorScount(n)=C; 
if 
(synch~count 
(rn) : =synchtcount 
(n)+1) 
> nflxScount 


then 
~o; 
synch~count 
(n) 
= 
(1; 
cqcnrf(n) 
cqcnr.f(n) 
or 
errorSflaq 
or 
initSrequest; 
enc; 
cl se 
cqcmc.f (n) 
=cqcm0f 
(n) 
or 
errorSfJ?g 
or 
synch~request; 


enc1; 
else 
cocmcfln) 
cgcnofln) 
or 
repeatSrpoupst; 


return; 


c-' 
-rrorSt.est; 


Seject 
f-1LINK: Procedure 
publ ic; 


/* 
Initialize 
the 
systeM 
;onr t.he t?sk 
*/ 
Do 
n=0 
to 
NSNODE; 
COr.~DFln)=synch~request 
or 
errorSfl~g; 
CQ~PAR(n) 
.run,CQ~PARln) 
.stoF,COMPARln) 
.aup$pt=C; 
ERRCR$CCUNT(n) 
=0; 
SYNCH~COUNTln)=n; 
eno; 


/* 
Initialize 
the 
node 
pointer 
*/ 
NODE$CNT=('; 


/* 
Initialize 
the 
input 
exchanges 
*/ 
Do 
N=r 
to 
n~noc.e; 
call 
RQCXCH(.CQ~IEXln)); 
call 
RQCXCHI.ACL~SEXCH(n)); 
end; 


/* 
Initialize 
the 
~ueues 
*/ 
call 
cqS~Sinit(.cqmstq, 
25~); 
c2ll 
ca~qSinitl.cqMsia, 
254); 


/* Crc2tc 
the 
n?meo 
exch;onges 
,nc 
give 
r;OM to 
fsm*/ 


Crll 
usrint; 


/* initi?lize 
the 
level 
7 
interrupt 
exchange 
*/ 


call 
rqelvl(7); 


/* Begin 
main 
task 
loor 
*/ 
[10 
forever; 


/* 
Regin 
support 
of 
one 
noeal 
,hcnnel 
*/ 


Do 
n=] 
to 
n~noc'e; 


J:f 
4 


1 ~ ('\ 
4 


] r; 1 
t 


] r; 2 
11 


1 r:; ~ 
Il 


](i5 
4 


11';7 
5 
1 r.; P 
c: 


H-S 
r. 


17r 
S 


171 
G 


177 
r,; 


17:' 
S 


171 
"- 


]75 
" 


17~ 
G 


/* reset 
cueue 
pointers 
*/ 


rq~s~c.give~ptr, 
ra~st~.t?ket-ptr 
\,; 


/* lor-pute 
nOr?] 
n00e 
numher 
*/ 
If' 
(cccncJf(n) 
?nr 
syncr~request) 
>r 


then 
out~o~e 
= 
]; 
else 
outmo~e 
= r; 
If 
(cqcr.lcf(n) 
?nG 
initSrecucst»r 
tren 
outmore 
= 
/; 
cc$~rtiveSno~e 
= 
n; 


/* if 
coron 
f?ilurp, 
kill 
2]] 
ness~ces 
*/ 


if 
(c~cm(lf(n) 
<>nr. 
prror~flcg) 
> r 


tren 
do; 
00 
while 
(msgSrtr:=raacpt(.conicx(n))) 
> 
r; 


c?ll 
rpturnSr~l'l 
(~sgSptr); 
enc; 


CO while 
(rnsg~ptr:=ro;>cpt(.rolclSexch(f'))) 
> r; 
c?ll 
rf'turnSr?ro(rnsgSptr); 
enc; 
E'n~; 


/* 0per?tp 
on 
noo?l 
nore 
*/ 
Do 
c?se 
outrno<'le; 


/* c?se 
V, 
routine 
communic~tion& 
*/ 


Do; 
If 
(cqcmdf(n) 
?nc 
rf'pe?tSreaupst»n 


thp.n 
co; 


/* support 
of 
retr?nsmission 
reauest 
*/ 


cqcmcf(n)=cacmrf(n) 
~nc 
not 
rppe?tSrecuest; 


msaSptr=ra?cpt(.rolcSexcr(n)); 
if 
msgSptr>r 


]f? 
P- 


I pI 
F 


]fS 
f 


If(j 
f 


1 f7 
8 


JP~ 
8 


] 
<; r 
8 


/* retr?nsmit 
010 
nessege 
*/ 


then 
['0; 
if 
cc~p2r(n) 
.n," 
= r 


then 
cqnp?r 
(n) .n? 
= 
J ~,; 
f']se 
cql"p?r(n) 
.n<>=ca~p?r(n) 
.n? 


- 
J; 
c?ll 
caSgenSms0(msg~ptr,n,.~sg, 


.carostq,.cqmp?r(n) 
,0); 


c?ll 
rqseno 
(.I~oJr'Spxch 
(n), 
msgSrtr); 
if 
rornp"'r 
(n) .n? 
= 
I!' 
then 
cql"per(n) 
.n? 
= r; 
else 
cqmp<>r (n) .na 
=col'lpi'r 
(n) 
.n;1+1; 


inter 


1 
7 
1 2 
f 
1 
... 
P 


I 
4 
8 


IS 5 
P 
lSr, 
7 


JS7 
f, 


E'8 
7 
IS? 
7 


/* no 
old 
nessa~e, 
send 
ready 
*/ 


else 
~o; 
msg.trgt==n; 
msg.cnnr:1==3; 
call 
ca$msg~out(r,.cqmstq, 
.•cqmpar(n) 
,.msg); 
end; 
end; 
/* enr 
of 
retransmission 
*/ 


/* support 
of 
next 
r.essege 
*/ 


elsp 
~o; 


/* clear 
~ol~ 
exchange 
*/ 


nsg~ptr==rqacpt(.ho!fSexchln)); 
if I'1sgSptr>O 
then 
ro; 


2 ['I 
2['2 


/* free 
SrACe 
return 
size 
*/ 


r2msize==~Atasblock.lpngth; 
if 
IUll'1size mod 
t!) 
> r 


then 
c'etashlock.length 
==cetaSblock.lenqth 
+14-lramSsizc 
mac' 4)); 
call 
ROSE~DI.rqfsrx,msgSptr); 


enc'; 


2C" 
P 
2[:5 
r 


2('0 
7 


2(.7 
7 


2[9 
P. 


/* test 
for 
a message 
output 
*/ 


msgSptr==rqacpt 
(.cqmiex 
In)); 


2]1 
212 


/* when 
a message 
exists 
*/ 


if 
msgSptr>r 
tren 
do; 
if 
(te 
rgpt$pxch: 
==fin (1 Sex ch (ms9 SP t r +?)) > r 
then 
call 
rqsenf(targetSpxch,msgSptr) 
; 
else 
co; 
call 
cq~gpn$nsg(msq$rtr,n,.nsg, 
.cqmsta,.cqnpar(n) 
,r:); 


cClI I 
rcsenrl (.holc'Sexch 
In) , 


msgSptr); 


21<1 
9 


21(; 
~ 


717 
9 
2][ 
8 


219 
7 
22r 
R 
221 
P 


/* incre?se 
tre 
nA 
flAg 
*/ 


if 
cqnperln).n? 
15 


then 
camper 
In) .na 
== r; 
else 
cmnp?r(n) 
.na 
== comp",rln) .na 
+ 1; 


enc1; 
en(l ; 


/* when 
no 
messaQe 
exists 
+/ 


else 
00; 
l':1sg.trgt==n; 
mS9·cmnc'==3; 


2/7 
e 


72:'l 
f 


2// 
7 


225 
I; 


.,..,r 
S 
L 
I. 
\. 


227 
5 


22P 
C, 


229 
r, 
2.3r. 
') 


221 
r 
" 


232 
r;; 
2"" 
S 


23;1 
C, 


235 
5 


2:(; 
r.; 


2:7 
I'; 


2:f' 
Ii 


23~ 
r; 


24C 
Ii 


21'1 
r: 
2L!2 
t; 


20 
5 


21''' 
;1 


2115 
4 


2~r; 
I) 


Crl1 
cq~~sg~out(r,.cqMstc, 
.cq~pi'r (n) ,.ms(1); 


C'nrJ; 
('n~; 
/* pn0 
of 
routine 
nesscge 
*/ 


/* sti'rt the 
npsscge 
tr2ns~ission 
*/ 


sta rt~54~ 
= n; 


/* c?se 
I, 
syncr 
request 
*/ 
co; 


cqmp2r(n) 
.nr,cqnp<1r(n) .1;> 


msg. t rgt=n; 
l'1sg.cmn~=I; 
c211 
cq~msg$out 
(C,. 
cqmstq, 
.campa r (n) ,.rnsg); 


st?rtS5;14 
= n; 
cqcnof(n)= 
cqcnrJf(n) 


an~ 
not 
synch$request; 


/* case 
2, 
initialize 
request 
*/ 
do; 


cqcmrf(n)=(rccrn~f(n) 
cnn 


not 
init~request) 
or 
synrh~rcquest; 


campi"r(n) .nco, cqnpar(n) 
.1<1 
= 
r; 


msg.trgt=n; 
msg.cnnr=('I; 
ci'll 
co~nsC1~out 
(r,.carnstC",.cql'1par(n),.1'150); 


start~5l!4 
= n; 


enc'; 


/* wait 
for? 
response 
from 
tre 
sl?ve 
*/ 


msg~ptr 
rqwcit(.rql~ex,25); 
start~5L1'" = r'; 


/* test 
for 
c 
Message 
or 
? 
timeout 
*/ 


if 
rrmSmsg.type=3 


/* support 
of 
no 
velie' 
r0sponse 
*/ 


then 
/* 
test 
for 
m?x 
number 
of 
errors 
to 
no~e 
*/ 


crll 
error~test; 


/* support 
of 
gooc 
response 
return 
*/ 


else 
00; 


if ca~checksuml.cq~siq)=r. 
t.hen 00; 


/* convert 
~~ssege 
to 
hex 
formAt. */ 


~All 
ca~Asc~~ex(.ca~siq,.~sg); 


/* test 
for 
rAta 
message 
receipt 
*/ 


if mSC1.CrlnC = 
2 


/* support 
re~eipt 
of 
0?te 
MPssase 
*/ 


tbel" rio; 


2 Sf 
7 
2:' :. 
7 
2:(; 
7 
257 
7 
2 sr 
7 


259 
7 


2~C 
7 


2 <: 1 
7 


/* aet 
r2m 
fro~ 
free 
spece 
~?n?aer 
*/ 


reQ~Msq.lenqtb=ll; 
re~SMs~.type 
= 
5; 
reqSmsg.resronseSexchenge=.~aSmsSex; 
rpqSmsg.msgSlength=msg.text(7); 
cell 
rqsenc1 (. 
rqfsox,. reoSmsg); 


msgSptr=rowait.l.cc$msSex,r); 
msgSptr=rpq~msg.msaS]engtb; 


/* Move 
rlcssege 
into 
mcmory 
*/ 


Ci"lJ ~ovelmsg.tf'xt(2),.nso.t€xt(r) 


,msClSptr) ; 


/* if 
target 
is ?nother 
node •• */ 


if l'lsg.trgt.> r 
then 
re]l 
rcsenol.cqMiexlmsq.trqt.) 
,msg$ptr); 
-- 


21)-: 
7 
9 ) ) 


;~: 7 
2C.~ 
7 


2 r:.'; 
f 
2':f' 
f 


2"7(' 
P 


77 J 
f 


then 


c21l 
rc;scnr(t?r<JetSexcr., rss~ptr); 
else 
00; 
r2rsizp 
= nsg.textI7'; 
jf 
(ri"~size 
11'0(' 
") 
> r 


tren 
r.sa.tpxt(2)=r.sg.textI2) 


+ 
(~ 
-Irensizc 
mod 
4)); 


cell 
rasenr'(.rc;fsrx, 
~sCl"'ptr); 


enc; 


2"'" 
7 
'''- 


27~ 
7 


275 
7 


27r 
" 


/* incre~pnt 
meSSAge 
counter 
*/ 


i f 
CQM['2 
r (I") 
• ] e 
= 
] ') 


trcn 
campAr(n) 
.]2 
= 
C'; 


else 
ccrnperln) .le=camp2r(n) 
.1i'+J; 


('1"(1 ; 


/* 
rcsponr' to 


if msg.cMl"c' 


inter 


27E 
(; 


2 E (I 
<:; 


2f' ] 
..,, 


2P3 
7 
281, 
P 


2F: 
p 


28ti 
P 
?f7 
7 
2PP 
h 


289 
5 
2~(; 
!' 


2S'] 
4 
2£2 
3 
293 
2 
294 
] 


enC'; 
enn; 
end; 


/* t~st 
for? 
gooe 
sl?ve 
L~ 
response 
*/ 


if 
cQMrer(n).n? 
= 
f.1sg.seqle 
+ 1 


then 
('"pll errorStest; 
else 
('0; 
if 
nsq.seqlC' 
<> 
cqmp?r(n) 
.ni'l 


then 
r.qcmc'f(n) 
= cqC"JTl('f 
(n) 
or 
synct"JreQuest.; 
else 
('0; 
errortcount(n) 
= f; 
cacJTlC'f(n) 
= c-qcm(lf(1"') 
and 
not 
errorSflrq; 
enc; 
end; 
end; 
/* end 
of 
response 
ret.urn 
*/ 
/* support. 
of 
hp(' ct"Jecksum 
*/ 
else 
cC'll 
errorttest; 
enC'; 


/* enC' of 
ness?ge 
?rrivee 
options 
*/ 


/* end 
of 
one 
noc'e */ 


/* end 
of 
tesk 
*/ 


inter 


$titl~('Sl~ve 
Conmunic?tions 
P?ckage 
Version 
3.7') 


CC~SLV$~Or-ULE: 
co; 


This 
is 
the 
sIeve 
communication 
m?in 
t?sk. 
It 
shoulrl 
be 
configurec 
into 
the 
system 
having 
the 
following 
parameters: 


T?s~ 
n?~e- 
CO~L~V 
T?s~ 
entry 
point- 
r.CSL~V 
TasK 
priority- 
as 
requirec 
Task 
stack 
length- 
100 


Th~ 
LIN¥ 
ane 
LOC~TE 
co~mancs 
of 
the 
user 
mi. t 
incluce 
the 
following 
statements: 


:Fn:CQSL~V.OP.J 
:Fn:C'CS35l.0BJ 
:Fn:CQCO"'.LJR 
:Fn:CORSLV.LIP 


Several 
system 
parameters 
must 
be 
oefined 


in 
the 
user 
code 
to 
cefine 
the 
mode 
ch?racteristics. 
These 
p~rcmeters 
are 
~efined 


as: 
ca$slac- 
a 
byte 
value 
provicing 
the 
nodal 
address 
of 
the 
commun- 
ic~tion 
node. 
fre$mem- 
an 
address 
v?lue 
which 
provices 


a 
pointer 
to 
? 
block 
of 
p~,.., to 


he 
assigned 
via 
the 
free 
sp~ce 
m~nager 
to 
the 
cOMmunications. 
ramSlen- 
an 
adcress 
value 
which 
indic?tes 


the 
size 
of 
the 
ahove 
block. 
*/ 
declare 
CQS12d 
byte 
external; 


Snolist 
Sinclude(:fl:commsg.elt) 
~eclare 
msgSform?t 
literally 
'structure 
( 
trgt 
byte, 
crnnd 
byte, 
seaSla 
hyte, 
seaSna 
byte, 
text(2SC" 
byte) 
'; 


ceclare 
queueSformat 
literally 
'structure 
( 


endSptr 
byte, 
giveSptr 
hyte, 
takeSptr 
byte, 


inter 


51 
1 


52 
2 


53 
2 


5<'; 
1 


~,5 
2 


5(, 
'} 


57 
1 


Sf 
2 
5~ 
2 
,,\, 
'} 
,,1 
1 


62 
2 


h~ 
2 
64 
1 


(;5 
2 
Gh 
2 
()7 
1 


r;r 
2 
(i ~. 
2 
7[' 
? 
71 
1 


77. 
2 
73 
2 


74 
1 


7':; 
2 


7~ 
2 


77 
] 


7P 
2 


7': 
2 


PI' 
2 
PI 
1 


P2 
7. 


~eclare 
p?rtforrnat 
literplly 
'structure 
10 
byte, 
ne 
byte, 
run 
hyte, 
stop 
byte, 
que~·pt. 
h-yte) 
, ; 
~inclur€(:fr:objrn2n.ext) 
RQCTSK: 
PROCEDURF. 
(STATIC~PTR) 
EXTERN~L; 
DECL~RE 
STATICt.PTR 
~DDRESS; 


RQCXCH: 
PROCEDURE 
(EXCHANGE$PTR) 
EXTERNAL; 
DECL~RF 
EXCHANGESPTR 
ADDRESS; 


E~'D RQCXCH; 
Sincluee(:fl:comcorn.ext) 
CQ$NEXTSGJVE: 
Procecure 
(qSptr,g 
iveSbyte) 
byte 
externa 
1 ; 
Declere 
qSptr 
eccress; 
Dpclare 
giveSbyte 
byte; 
end 
cqSnextSoive; 
CQSTI'KESTEST: 
Procedure 
(qSptr) 
hyte 
externel; 
Declare 
aSptr 
eceress; 
'"", '-qSteke$test; 
CO$NF.XT~TAKE: 
Procedure 
lqSptr) 
byte 
externAl; 
Dccl0re 
qSptr 
accress; 
ene 
cq$nextStakc; 
CQSQSJNIT: 
Procecure 
(qSptr ,qSsi ze) 
extf~rna]; 
Declare 
q~ptr 
peeress; 
Declprc 
qSsizc 
byte; 


end 
cqSq~init; 
CQS~SC$HEX: 
Procedure 
lq$pt r ,rnsgSpt r) 
extern",l; 
Dee lare 
(qSptr ,fT1sgSptr) 
pod ress; 


en(~ co$ascSrex; 
COSCHFCKSUM: 
Procccure 
(qSptr) 
tyte 
externpl; 
Declare 
q$ptr 
adcress; 
end 
cq$ehecl<sum; 
CQSHEXS!'SC: 
Proeecure 
lQ~ptr,hex$byte) 
external; 
Declere 
cSptr 
Clrlclress; 
Deelpre 
hexSbyte 
byte; 
pnr 
cq$hex~esc; 
Ct:;'~t-"SGSOUT: 
Proeerure 
(rnsg$size,q$ptr,p2.rSrtr,msg~ptr) 
external; 


Dee]pre 
msgSsize 
byte; 


inter 


83 
2 
e4 
2 
85 
] 


8(; 
2 
87 
2 
PS 
'2 
89 
1 


S>0 
'2 
91 
2 
92 
2 
93 
1 
~4 
1 
95 
1 
g(; 
1 
97 
1 


9P 
1 


99 
2 


IrO 
1 


HI 
2 


If.2 
1 


H3 
2 


1C4 
2 


IrS 
1 


H'1 
2 


10; 
1 


HE 
1 
10~ 
1 


11r 
1 
111 
1 
112 
1 


113 
1 


Ceclere 
(C!~ptr,per~ptr,msgSptr) 
address; 
end 
cqSmsgSout; 
CQSGEN$RDY: 
Procp~ure 
(t rget ,rnsg~ptr,a~ptr, pi'! 
rSptr) 
externa 
l; 


Dec1ere 
trget 
byte; 
Declare 
(msg$ptr,q$ptr,pnr$ptr)'a0~r~ss; 
enr' cq$genSrdy; 
COSGENSt-1f,G: 
Procedure 
(rnsg~pointer,trget,msgSptr,q$ptr,pcrSptr,sev 
eSflg) 
extern"l; 
Declare 
(trget,saveSflg) 
byte; 


Declere 
(msgSpointer,msg$ptr,aSptr,p?r$ptr) 
"ceress; 


end 
cqSgenSmsg; 
Declere 
ROL~FX 
intSexchange$o€scriptor 
public; 
Peelere 
CQSJEX 
exchenge$descriptor 
public; 
Declare 
cMrqex 
exch?ngeS~escriFtor; 
c'eclilt'.<if JclSsl2veSex 
exchanqeSdescriptor 
public; 
Declare 
cqtiMe 
exch"nge$cescriptor 
public; 


cq$startSmsgS351: 
procedure 
external; 
end 
cqSstart$msgS35l; 


cqSinitS351: 
procedure 
external; 


end 
cqSinit~351; 


·finf.Sexch: 
procedure(nameSptr) 
address 
external; 
declere 
nameSptr 
address; 
end 
find$exch; 


cqSstartup: 
procedure 
external; 
enc' cqSstartup; 


declare 
caSin$sl 
queue$format 
public; 
declare 
cqSoutSsl 
queueSformat 
public; 
c'eclare msg 
msgSformet; 
declere 
ca~pars 
par~forMet 
public; 


declare 
freSmem 
ad~ress; 
c'eclare cqcmc'f(5) 
byte 
externel; 


c'ecl0re 
freSmsg 
based 
fre~mem 
structure 
msg$h~ 
r 
); 


The 
messege 
which 
is 
trensmittec' 
between 
nodes 


follows 
the 
description 
below: 


inter 


Vith 
the 
excpption 
of 
the 
stert 
of 
text 
(~ 
line 
feed) 
enr. 
the 
eno 
of 
transmission 
(~ cerriage 
return), 
~ll 
charocters 
transmitted 
in 
the 
~eSSAge 
string 
will 
consist 
of 
print?ble 
ASCII 
charActers. 


The 
target 
fielc 
consists 
of 
two 
frames 
which 
represent 
the 
hex 
edfress 
of 
the 
fevice 
to 
which 
the 
Message 
is 2crlressec. 
The 
protocol 
~llows 
for 
up 
to 
25~ 
unique 
device 
~ddresses. 


The 
comm?nd 
field 
indicates 
the 
type 
of 
mess~ge 
which 
is being 
seht 
in 
the 
network. 
It consists 


of 
a 
single 
fra~e 
representing 
a hex 
nu~her 
in 


the 
renge 
from 
C to 
CFH. 
The 
current 
mess~ge 
definitions 
ere: 


comme-nd 


('I 
1 
2 
3 
4 
5 
n 


lebel 
INIT 
SYt-'CH 
Dl'Tl> 
REl>DY 
NOT 
REl'DY 
NON 
fF.O 
'.CI< 
reservF'c' 


This 
is 
the 
main 
link 
level 
R~X/pr 
connurricetions 
task 
which 
supports 
sl~ve 
oper~tions 
of 
~ 
single 
hoarc. computer. 
Several 
high 
levF'l functions 
arF' 


supported 
by 
this 
tesk. 


Messages 
containing 
feta 
may 
be 
sent 
or 
receiver 
by 
this 
tesk. 
To 
sene' a message 
to 
enother 
processor 
on 
the 
communications 
loop, 
a messagE' 
of 
the 
format 
shown 
is placed 
into 
the 
co~munications 
exchange, 
CQSIF.X. When 
the 
~essage 
has 
been 
transmitted, 
,the 
R'~Area 
in which 
the 
message 
was 
locater. will 
be 
returned 
to 
the 
free 
space 
manager. 


Messages 
mey 
also 
he 
receiver 
by 
the 
boarc 
wren 
they 
are 
addressed 
to 
the 
communications 
aderess 
essianee' 


to 
tris 
board. 
~hpn 
a message 
res 
bF'en receivF'd,"it 
will 
be 
transferred 
to 
e 
block 
of R"~ obteinec' 
from 
the 
free 
sp?ce 
maneger 
and 
then 
sent 
to 
an 
excrenge 
which 
is fesignated 
in 
tre 
name 
fielc 
of 
the 


messa(1e. 


intel 


llt: 
1 


115 
7. 


llG 
;> 
11 7 
;> 
lIP 
7. 


lEI 
;> 


12(' 
;> 


121 
2 
122 
2 
123 
2 


12L1 
2 


12~ 
2 


1211 
2 


127 
2 
12E' 
2 


179 
2 


1:C 
:: 


The 
form?t 
for 
? 0ata 
ness?ge 
is: 
msgShdr 
trrgetex~hangen2me 
message 


A 
special 
comm~nd, 
I~IT, 
can 
be 
received 
by 
the 
cowmunir?tions 
driver 
task 
w~ich 
will 
cause 
a 


software 
reset 
of 
the 
single 
borrd 
computer. 


ceclrre 
target~Exrh 
~('clare 
n?me 
Df'cli"re rnsg~ptr 
<"€Clerc 
rrmsize 


a<"c'ress; 
i?rdress; 
2ccJress; 
ade1ress; 


Decli?re RA~Smsg 
b?sed 
nsg~ptr 
structure 
msgShrr 
);" 


Declare 
reqSmsg 
structure 
msgShcr, 
nsgSlength 
pecress 
); 
/* initialize 
the 
ti?sk at 
power 
up */ 
call 
cqSqSinit(.cqSinSsJ, 
25C); 
call 
cqSqSinitC.cqSoutSsl, 
25~); 
cqSpi?rs.run, 
cqSpars.stop, 
cqSpars.queSpt 


/* 
build 
required 
exchanges 
*/ 
cilll rq('xch(.rqlliex); 
call 
rqcxch (.cqsiex); 
call 
rqcxch (.cmrqex); 
c2011 rqcxch(.cqtiMe); 
crll 
cqinitS351; 


/* writ 
for 
e 
window 
from 
the 
wrster 
*/ 
nsgSptr 
= 
rcw20it 
(.RQLhEX, 
~r0); 


/* test 
for 
the 
receipt 
of 
r 
"ali0 
messoge 
*/ 


if caSchecksun(.~qSinSsl) 
= 
() 
then 
do; 


/* ~onvert 
the 
ness20ge 
into 
hex 
format 
*/ 


('all cqSascSbex(.('a~inSsJ,.msg); 


/* see 
if message 
is 
for 
this 
sJrve 
hoard 
*/ 


if msg.trgt 
= 
ccsl~d 
then 
<"0; 


/* 
init~ilizc 
r~~~ 
OU~UPS 
*/ 


C"•• ~J 
r-q:;:a~jnit 
(_cq~in~eJ 
•.~5r'); 


~~J~ 
~qSq~init 
C_~~~ou~~s~,~S0); 


/* 
c~tucn 
non 
sea 
~ck 
m~ss~g~ 
-/ 


nsCJ_ 
cCJt': 
r; 
msg_~mn~ 
_ 
5; 


~Ft~~ 
C-qS"MSq~OU~ 
CO 
•. _c-qS"out~sl 
•.• 
C-Q~ 


/- 
r~st 
For 
coccrc-~ 
N~ 
*/ 


iF 
C"qp~cs_n~ 
- 
msq_scq~n~ 


~hrn 
do; 


; 
F 
MSC1'~pt-r 
> 
n 
~r~n 
c-~J~ 
r~t-u~n~r~~(Ms~~ptr) 


/* 
jncr~M~nr 
L~ 
coun~rr 
*/ 


j~ 
(cq~p~cs_lr:-c-q~prcs_Jr+J 


T7'RGF"T~EX(""'l 
- 
FTl"n$F"xrH 
(n"fTl0) 
iF 
T7'R~~T~px~h 
> 
r 
~""ron 
c"'o; 


11;4 
][' 


= 
.c:mSrCl~€'x; 


1(-;5 Ir. 


ext(2); 


IhG 
H 
msg) ; 
11>7 
lr. 


x, 
C); 


He 
H 


th; 


1'-9 
lC 


g.text 
(r), 
msgSptr); 


PC 
][' 


msg~ptr) 
; 


171 
1(' 


/ 


172 
S 


]""73 
S 


('"q~out!"'sl, 
.caSp?rs); 


]75 
9 


]713 
H 


I"> 
(Msgptr 
+ 
9) ) 
> r 


ch, 
msgSptr); 


17£ 
]0 


179 
11 


18e 
]1 


]P ] 
11 


11'2 
Ie; 


If'3 
9 


mS9~ptr 
= RQ~CPT 
(.c:qsiex); 


if msgSptr 
= r 


then 
c:",11ca$genSrcy 
!(',.msg,. 


else 
ro; 
if! 
tnrget~exch:= 
finc$cxc 


else 
do; 
\.ell 
cqgenSmsCl(msgptr, 


] I'll 
P 


IPS 
9 


]f'&; 
~ 


IF7 
9 


189 
][' 


1% 
Jr 


191 
Jr. 


lS2 
9 


else 
do; 
c:qp2rs.n? 
= msg.sE'~$n?; 


nsg$ptr 
= 
rq?cpt(.l">o!c'$sl?vp$e 


if msg$ptr 
> 
(' 
then 
00; 
('"211caSop.n$msg(msg$ptr,r, 


enr1; 
enC'; 


193 
P 


194 
fl 


) 95 
7 


lS<; 
P 


2 C] 
20.2 


2r7 
JC 
2C8 
) ) 
ns 
11 


21r 
J ) 
211 
) r 


/12 
~ 


21: 
F 
21~ 
S 
215 
9 


?lfi 
9 


21P 
Ie 


21~ 
1" 


22C 
lC 
221 
9 


/* sene 
mess?ge 
*/ 
c?ll 
cc~st?rt~~sg~~~I; 
cn(l; 


/* c?se .3, PDY comm?n(l */ 
00; 


/* verify 
ne 
is correct 
*/ 


if ca~p?rs.n? 
msg.seq$n? 


t.hen 
ro; 


/* clp?r 
ole messages 
*/ 


msg~ptr 
= 
raacpt(.hol(l$sl?ve~e 


if l':1sgtptr> r 
then 
call 
return$r2m(msg~ptr); 


msgSptr 
= RQ~CPT 
(.cqsiex); 


if msg$ptr 
= 
(1 
then 
call 
cq~gen~rdy 
([,.l11sg,. 


else 
00; 
if 
(targetSexch:=find~exch 


else 
~o; 
cell 
cq$genSmsglmsgSpt 


end; 
en0; 


else 
00; 
capars.na 
= Msg.seq~na; 


rnsg~ptr = ra?cpt(.hole$sl?veSe 


if msg~ptr 
> r 
then 
(lo; 
call 
cqSgen~msg(msaSptr,r, 


end; 
end; 


222 
f' 
223 
f' 


224 
7 


22" 
7 


22? 
7 


23[, 
.., 
I 


232 
7 


234 
7 


23(- 
7 


2Jr 
7 


21.[, 
7 


242 
7 


241, 
7 


24fi 
7 


2"1: 
7 
2 L: ~~ 
r. 


25C 
5 
251 
<'1 


2 c;~ 
3 
J£ 
253 
t 
254 
5 
255 
5 


25t; 
4 


257 
5 
2 Sf 
5 


c~i1 
ccSst~rt~msg~351; 
enn; 


1* 
c~se 
4, 
~CNRrY 
conm2nc 
*1 


do;end; 


1* ccse 
5, 
NONSEQACK 
comMand 
*1 


c'!o;enc; 


1* 
C2se 
n, 
reserved 
*1 
do;enc; 


1* 
C2se 
7, 
reserved 
*1 
co;end; 


1* 
case 
R, 
reserven 
*1 


no;end; 


1* case 
9, 
reserved 
*1 
c'!o;end; 


1* 
c?se 
A, 
reserved 
*1 


do;enc; 


1* 
C2se 
E, 
reserved 
*1 


do;cnd; 


1* 
c~se 
C, 
reserved 
*1 


do;eno; 


1* cpse 
D, 
reserved 
*1 


do;end; 


1* 
case 
E, 
reserven 
*1 
do;end; 


1* 
cpse 
F, 
reserved 
*1 


do;enc1; 


end; 
1* 
do 
case 
*1 


end; 
1* 
gooo 
target 
*1 
end; 
1* 
oood 
checksUM 
*1 
end; 
I*gooo 
~ommunications 
with 
i~OS*1 


1* 
clear 
out 
messages 
if 
~o~ 
f?ilure 
exists 
*1 
el.se 
00; 
00 
loJhile (mso$ptr:=rc?cpt(.cosiex)) 
> 
f; 


call. 
returntram(msgtptr); 


(10 
while 
(~sgtptr:=ra?cpt(.holc'l~sJ?ve~px)) 
> 
~; 


call 
return~r?m(msg~ptr); 


cqcmcfCl") 
= cocmdf(C) 
or 
flC-h; 
E'nCl; 


E'nc; 
/* do 
forpver 
*/ 
enc1 
cc$s12v; 
enc 
comslvSnoCiule; 


inter 


Stitle('QUEUE 
INITI~LJZATION 
PROCEDURE') 
Q~INIT~~ODULE: 
Do; 


~ecl?re 
~om 
liter?lly 
'rcp'; 
Sinclude(:fl:commsg.elt) 
cecJare 
msg~format 
liter?lJy 
'structure 
( 
trgt 
hyte, 
cmnc' 
byte, 
scqSle 
hytp., 
seqSna 
hyte, 
text(25C) 
byte) 
'; 


c'er.LH' 
qucueSformr>t 
liternlly 
'structure 
( 
en(Sptr 
hyt~, 
give~ptr 
byte, 
t?ke~ptr 
byt~, 
c'ete$byte(254) 
byte) 
'; 


~ecl?re 
perSforrnat 
literally 
'structure 
( 
Ie 
byt.e, 
na 
byte, 
run 
byte, 
stop 
byte, 
queSpt 
byte) 
'; 
Sinclude(:f0:synch.ext) 
RQSEND: 
PRCCEDURE 
(EXCHANGE$POINTF.R,~ESSAGF.~POINTF.R) EXTERNAL; 


DECLARE 
(EXCHANGE~PCINTER,MF.~SAGESPOJNTER) 
ACDRESS; 


RQW.aIT: 
PROCEDURE 
(EXCHANGESPOINTER,DEL.ay) 
ADDRESS 
EXTERNAL; 


DECLARE 
(EXCHANGESPOINTER,DELAY) 
ADDRFSS; 


RQ~CPT: 
PROCEDURE 
(EXCH}NGE~POJNTER) 
ADDRESf 
EX~ERN}L; 


DECLAPE 
EXCf~NGESPOINTFR 
~DDREff; 


ROISND: 
PROCEDURE 
(IED~PTR) 
EXTF.PNAL; 


DECLARE 
IED~PTR 
ADDRESS; 


END RQISND; 
Sincluc'e(:fr:~xch.elt) 
DECL~RE 
EXCB}NGESDE~CRIPTQR 
LITERALLY 
'STRUCTURE 
( 
MSGSHEAD 
PDDRESS, 
~SG$T.arL ADDRESS, 
T~SKSHEPD 
PDCRESS, 
TASKSTAIL 
}DDRE~S, 


NF.XT~F.Xrp~rDRF~8) '; 
~in'lu0e(:fr:msg.eJt) 
Dr.CLARE ~SG~p.rF LJTF.RALLY , 
LHIK 
'DCRFES, 
LENGTH 
'[,DRE~S, 
TYPE 
PYTE, 
HO~EtF.XCP.'NGE'DDRESS, 
RESPCNSESEXCH'~GE 
'DCRESS'; 


rECL'pF. ~SGSrE~CnJPTrR 
LTTEr'LLY 
'STRUCTURE( 


r-lfGSHDR, 
RE~JlI 
.~1F:1 (J) 
PYTE) 
'; 


de,Jare 
timex 
exchanac~res,riFtor 
external; 


<'(',l?re'rqfsrx 
f'xch?~ge~rescrirtor 
ext.ernCll; 


CCSQSINIT: 
Proce<'ure 
(queueSptr, 
qucueSsize) 
reentrant 
pub 


J i,; 


/* 
This 
procedure 
initi?lizes 
the 
queue 
pointers 
to 


in<'icate 
an 
empty 
queue. 


Declare 
queueSptr 
?o<'ress; 
Declare 
aueue~size 
byte; 


end 
cc;SCj~init; 


enc 
q~inittmo<,ul€; 


inter 


f. 
1 


7 
2 


e 
2 


S 
1 


H 
/. 


11 
2 


12 
1 
P 
/. 


14 
? 


1~ 
1 


] (-. 
2 


J7 
2 


]f 


Stitle('NEXT 
CIVE 
QUEUE 
PROCEDURE, 
VERSION 
2.1') 
NEXT$GIVEt~ODULE: 
Do; 


0ecl?re 
eorn liter2lly 
'r.DH'; 


Sincluc'e(:fl 
:comr.>sg.elt) 
c'eclare 
msgSfornat 
literally 
'structure 
( 
trgt 
byte, 
Cl7lnc' 
hyte, 
seaSli'l 
byte, 
s£'qtn? 
byte, 
text(2"'0) 
byte)'; 


declAre 
queueSforrnct 
literally 
'struct~re 
( 
encSptr 
byte, 
giveSptr 
byte, 
t?~eSptr 
hyte, 
c1?t?Sbyte (254) 
byte) 
'; 


c'ecli'lrep?rSformet 
literally 
'structure 
( 
1<1 
byte, 
ni'l 
byte, 


Cu': 
byte, 
stop 
byte, 
queSpt 
byte) 
,; 
Sinclude(:fr:syncr..ext) 
RQSEND: 
PRCCEDURF 
(E~CH~NGE$prINTER,~ESS~GF$P0INTER) 
EXTFRN~L; 
DECL~RE 
(EXCH~NGE$POJNTER,~ESS~GE$P0INTER) 
~DDRE~S; 


RC'''':~IT: 
PROCEDURE 
(ExrH~NGESPOINTER,DEL~Y) 
~DDRESS 
EXTERNAL; 


DECLARE 
(EXCHPNGF$POINTE~,DELAY) 
~nDPESS; 


POP-CPT: 
PROCEDURE 
(EXCHPNGE$POINTER) 
~rDRESS 
F.XTERNPL; 


DECLARE 
F.XCHANGESPOINTER 
ADDRESS; 


RQJSND: 
PROCEDURE 
(TFDSPTR) 
EXTERNAL; 


DECLARE 
IEDSPTR 
~DDRES~; 


END 
RQTSND; 
Sipclude(:f0:exch.elt) 
rECL~RE 
FXCPANGF.$DESCPJPTOR 
LJTER~LLY 
'STRUCTURE 
( 
~SG$RE~D 
ADDRESS, 
~SG$T~IL 
ADDPE~~, 
T~SKSHEPr 
PDDRESS, 
TlSK$TAJL 
~rDPESS, 


intel 


2'1 
2 
25 
2 


2f 
2 
27 
2 


21' 
2 


2~ 
2 
3r. 
'? 


32 
:] 


33 
~ 
31! 
3 


3~ 
2 


NFX7~EXCH 
JDCRFSS) 
'; 
$inclure(:fr.:msg.~lt) 
rECL~PE 
MSGSHPR 
LITF.R~LLY 
, 
LH'f( 
lCDRESS, 
LEt.'GTHflDDPEfS, 
TYPE 
PYTE, 
HO~F~EXCHJNGE 
"DDRF~S, 
RESPCNfF.~FXCP."NGE 
flPDRFSS'; 


DECLIRE 
~SGSDESCRIPTOR 
LITFRALLY 
'STRUCTURE 
( 
!'1SGSPCR, 
RE~1f1INDER (1) PYTE)'; 


cec12re 
timex' ex('hange~<"escrip!:or 
f'xtcrnel; 


Cf'('i.~r( 
rgfsrx 
exchengeSc'escriptor 
E'xternC'l; 


CQSNEXTSGIVE: 
Procedure(OUEUE~PTR,GIVESBYTE) 
byte 
reentran 
t public; 


/* 


This 
proce~ure 
pl?ces 
a byte 
into 
the 
cueue 
if 
room 
exists 
in 
the 
queue 
for 
that 
byte 
of 
rC'ta. If 
no 
room 
exists, 
~ queue 
full 
indicC'tor 
will 
he 
returned 
by 


the 
procecure. 


Deelere 
OUEUESFULL 
literally 
'0FFH'; 


Decl?re 
QUEUESOK 
literally 
'CErH'; 


Decl?re 
QUEUESPTR 
a<'<'ress; 
Declare 
(GTVESBYTF,RSLT) 
byte; 


/* Test 
for 
cueue 
full 
corrition 
err 
if 
it is 
full, 


then 
insert 
pnc' of 
messege 
*/ 


RSLT 
= queueSok; 


If 
(quEue.GIVESFTR+l 
> oueup.ENDSPTR) 


then 
ro; 
rsl t 
= oueueSfull; 
gueue.c~teSbyte(queup.qiveSptr) 
eon; 


r::nr; 


inter 


> queue.EN[,~PTR) 
then 
oueue.GIVEtPTR 


('1"'(1 ; 


pnc 
cq~nexttgjv('; 
enc 
next~aive$~o~uJe; 


inter 


(j 
1 


7 
2 


p 
2 


9 
1 


1r 
" 
11 
7 


1 2 
1 


13 
2 


14 
:2 


15 
1 


1G 
2 


17 
2 


1P 
1 


~tit1e('GET 
CHlRACTER 
FRr~ 
QUEUE 
PRnCEDURE') 
NEXT~TlKE~~0DULE: 
Do; 


drc1?re 
eorn literally 
'rDH'; 
~ inc J uc'e (:f) 
: C"oMrnsg•Po] t) 
rec1?re 
msg$for~?t 
literally 
'structure 
( 


trgt 
byte, 


Cl"nr 
byte, 


,.......,.t 12 
byt.e, 
seo~n? 
hyte, 
t ext ( 2 5r ) 
hy t e 
)'; 


dcclcre 
aueueSforp?t 
literally 
'structure 
( 
enc'$ptr 
byte, 
give~ptr 
byte, 
takeSptr 
byte, 
d?tC'$byte 
(2~L1) 
byt.e )'; 


reclare 
par$forM?t 
literally 
'structure 
( 
Ja 
byte, 
na 
byte, 
run 
hyt.e, 
stop 
byte, 
queSpt. 
byte) 
,; 
Sinclure(:f0:syncr.ext) 
R('SEND: 
PROCEDURE 
(EXCHlNGESPOINTER,MESS~GESPOJNTER) 
EXTERNAL; 


DECL~RE 
(EXC~~NGESPOINTER,~ES~~GEr.POINTER) 
ADDRESS; 


PQI-"l'JT: 
PROCFDURF, 
(FX~H~NGF$POINTER,DF,Ll'Y) 
lDr-PEfS 
EXTFRNlL; 


DECL~RE 
(EXCH~NGE$POJNTER,DELPY) 
~nDRESS; 


P('JlCPT: 


PROCEDURE 
(EXCHANGE$POJNTFR) 
rDDRESS 
EXTERNA~; 


DECL?RE 
EXCHANGE$POINTER 
~nPRFSS; 


ROISND: 


PROCEDURE 
ITEDSPTR) 
EXTERNAL; 
DECLARE 
JED$PTR 
r-DCRESf; 


END 
RQJSND; 


$incJuc'e(:f0:excr.elt) 
DECLJlRE 
EXCHANGESDESCRJPTCR 
LITERALLY 
'STRUCTURE 
( 


~SG$HE}lD 
l'CPRESS, 


MSGSTAJL 
ADCRESS, 
TASK$PEAD 
JlDDRFSS, 
Tl'fK~T}lJL ~rDRESS, 


NEXT~fxrH 
rDDRFSS) '; 
Sinclune(:ff:msg.clt) 
DECL~RE 
~~G$HDR 
LITERALLY 
, 
LINK 
lDDRESS, 
LENGTH 
lIDDRF.~S, 
TYPE 
PYTE, 
HC~E$EXCH~NGE 
lIDrPESS, 
RESPONSF$EXCI1H1GF 
!'l)DRES~'; 


DECLPRE 
~SG$DE~CRIPT0R 
LITEPALLY 
'STPUCTURF( 
~fG$HDP., 
RFfv'AINDFR(1) BYTE)'; 


~ecl?re 
tinex 
exchpnge$rescriptor 
externeJ; 


(~L_2rc 
rqfsrx 
pxchcnge$rescriptor 
extern?l; 
crr~rX~~TrKf: 
Frocerure 
(qucue$ptr) 
hyte 
rccntr2nt 
puhlic; 
/* 
This 
typcr 
proce~urc 
gets 
the 
next 
byte 
from 
the 
invicpter 
queue 
nn~ 
returns 
it 
to 
the 
cellin9 
progr2m. 
The 
cueue 
t?kd 
pointer 
is 
incremente~. 


Declare 
cueue$ptr 
?frrcss; 


Decl?re 
tpke$hyte 
hyte; 


If 
((queuE'.TJlKEtPTR: =oueup. TlKE~PTR+l) 
> 
queue.END$PTR) 


then 
queue.TlIKE$PTR 
= r; 


cnf 
cq$npxt$t2~P; 


ene 
nextSt?ke$morulc; 


£titlc('I~CII 
to 
HEX 
CONVERSION 
PROCEDURE') 


AEC£ 
'~v~~OrULE: 
Do; 


rpc12re 
pam 
lit€r~lly 
'r~H'; 


~inclu0e(:f]:r.o~~sg.elt) 
reelere 
Ms~£forn?t 
liter?lly 
'structure 
( 


trgt 
bytp, 
cnnr' 
byte, 
seq~l" 
byte, 


seO'~nc 
hyte, 
text (7~r) 
byte)'; 


necl?re 
cueuetforMet 
liter?lly 
'structure 
( 
enc~ptr 
byte, 
give~ptr 
byte, 
t?k~£ptr 
byte, 
r?t",Shyte(:?511) 
byte) 
'; 


reclpre 
p?rtform?t 
literAlly 
'structure 
( 


Je 
byte, 
n~ 
byte, 
run 
byte, 
stop 
byte, 
que$'pt 
byte) 
, ; 


Sjnclude(:f~:syncr..ext) 
ROSEND: 


PROCEDURE 
(EXCH~NGESPOINTER,~ESS~GE~POINTER) 
EXTERNAL; 


rECL~RE 
(EXCH~NGEtPOINTER,~ESS~GEtPOINTER) 
PDDRESS; 


f'(l1':PIT: 
PROCEDURE 
IEXCHPNGE$POINTER,DELPY) 
.aDDRESS 
EXTFRNPL; 


DECLARE 
(EXCHANGEtPOTNTER,DELPY) 
pnDRESS; 


R('lI.CPT: 


PROCErURE 
(EXCHANGF~prTNTER) 
ADrRESS 
FXTERNAL; 
DECLPRF 
EXCI1HTGEtPCINTER 
ADDRF.SS; 


R('ISND: 
Pf'CCFDURF 
(IErtPTR) 
F.XTERN1L; 


DECLARE 
TED£PTR 
f.DCRESS; 


END 
PC ISt-'D; 


Sinclude(:fC:exrh.elt) 
DECL~RE 
EXCHANGESDESCRTPTOR 
LTTER~LLY 
'STRUCTURE 
( 


~SC$HE~D 
ADDRESS, 


~SG$T~TL 
ADDRESr, 
T1SKSHEAD 
PDDRESS, 


TfSKSTAIL 
lDDRE~S, 


inter 


21 
1 
2/. 
1 
2: 
1 


2'1 
2 
25 
2 


2:-; 


27 
2 
28 
2 


2~ 
2 


3C 
2 


31 
2 
32 
2 


3: 
2 


35 
2 


3E 
2 


38 
2 


3~ 
2 


<'If 
2 
<'11 
2 


4: 
2 


NEXT~EXCH 
~DDRFSS) 
'; 
tipclude(:fr:~sq.elt) 
DECLARE 
~~GSHDR-LTTFPALLY 
, 
LINK 
.ADDRFSS, 
LENGTH 
l'DDRF'Sf:, 
TYPE 
P.YTE, 
HO~ESEXCHANGE 
ADrRES~, 
RESP0NSESF.XCHANGE 
'DDRESS'; 


DECLARE 
MSGSDESCRJPTOR 
LTTER.lILLY 'S7RurTURE 
( 
MSCSHDR, 
.,t.,JlTNDER(l) BYTE)'; 


declere 
ti~ex 
exchengeS~escriptor 
0xternel; 
declare 
rqfsrx 
pxch?n~eSdescriptor 
extern?l; 


cqSnextStc>ke: 


proce~ure 
(Q$ptr) 
byte 
extern?l; 


declere 
q$ptr 
a~dress; 
enc. 
cqtnextStake; 


7his 
procer.ure 
transforms 
JlSCII cet? 
in 
the 
input 
queue 
into 
e 
hex 
string 
in 
the 
system 
mASS?ge 
storage 


a ree • 


Declere 
(nchar,ch?r,n) 
I:::yte; 


Declare 
(q$ptr,~sg$ptr) 
?~dress; 


/* throw 
aWey 
the 
st?rt 
of 
ness?ge 
*/ 
crer 
= 
cqSnextSt?ke(qSptr); 


/* convert 
rnessege 
target 
eor-ress */ 
ch,u 
= 
cqSnextSteke 
(qSpt r) ; 


nch?r 
= cqSnextStake(qSptr); 


if 
cha r 
> 
l! Cr 


then 
char 
cher 
- 
37h; 


else 
char 
= 
cher 
- 
?0r; 


if 
ncha r > 
4Ch 


then 
ncher 
pcher 
- 
37h; 


else 
nCD?r 
= 
nchar 
- 
?rh; 


/* convert 
comMend 
byte 
*/ 


cher 
= cqSnextStekelq$ptr); 
if 
cher 
> 
<'Ifh 


then 
cher 
cher 
- 
37h; 


else 
ch?r 
= char 
- 
?rh; 


<':<1 
2 


45 
2 


.1) 
2 


H 
7. 


liS' 
7. 


5[' 
2 


5] 
2 


53 
2 


5<" 
2 


S8 
:' 


r,r. 
, 


r,1 
3 


1"3 
3 


(it, 
3 
f;5 
:3 
f;1i 
., 


r;7 
2 
of' 
1 


/* convert 
L~ 
sequence 
*/ 
d~C'r = cq~n(>xt~t;>k€'(qtFtr); 


if 
cher 
> 
Ll(1h 
then 
ch?r 
ch?r 
- 
~7h; 


else 
char 
= 
ch?r 
- 
:'C'h; 


/* convert 
N~ 
sequence 
*/ 


char 
= cq~nextSt;>kp(q~p~r); 


if 
C"h?r > 
~C'h 


tJ--enc1,ar 
ch?r 
- 
37h; 


else 
char 
= 
chC'r - 
3rh; 


n = 
C'; 
Do 
\·;hile (ch?r:=r.qSnext~take(O;pt.r)) 
<> 
F8~; 


if 
char> 
tlCH 
then 
char 
char 
elsE' ch?r 
= 
chi1r 
?7H; 
3CB; 


jf 
nchar 
> 
~C'H 


then 
nch~r 
nch;>r - 
37"; 
else 
nch?r 
= 
nch?r 
- 
'0"; 


msg.text(n) 
= shl (d'?r,<':) + 
nch2r; 
n 
= 
n + 
1; 
pnCl; 


enc' cq$asc$hex; 
en0 
ascthex$~oc'ule; 


r: 
1 


7 
2 


8 
2 


<? 
1 


1 r: 
2 


11 
2 


J 2 
1 


1:: 
2 


II! 
2 


1~ 
1 


1G 
2 


17 
2 


H 
1 
~ 


Stit1cl'AEX 
TO 
~SCII 
CONVERSION 
PROCEDURE', 
HEXSASCS~ODULE: 
Do; 


'ecli'rp 
f'OI'l 
literally 
'rOA'; 
S inc 1 U0 e (:f 1 :comnsg. 
C' 1t) 
oecl~re 
msgSformat 
liter21ly 
'structure 
( 
trgt 
hyte, 
cmn(1 
byte, 
seq$l2 
bytf', 
seqSne 
hyte, 
text (25(;) 
hyte 
)'; 


declare 
queue$format 
literally 
'structure 
( 
enoSptr 
byte, 
giveSptr 
byte, 
takeSptr 
byte, 
aataSbyte 
(254) 
hyte 
)'; 


declare 
r~rSform?t 
literally 
'structure 
( 
In 
byte, 
nC' 
byte, 
run 
byte, 
stop 
bytp, 
que$pt 
byte) 
,; 
Sinclude(:f0:syncr..ext) 
ROSEND: 
~RCCEDURE 
(EXCH~NCE$PCJNTER,MESSAGESPCJNTER) 
EXTERNAL; 


DECLARE 
IEXCH~NGESPOJNTER,~ESS~CF.$POINTER) 
ADDRESS; 


R0\"~JT: 
PROCEDURE 
IEXCAANGE$PCINTFR,DELAY) 
ADDRESS 
EXTERNAL; 


DECLARE 
(EXC fl~NGESPO INTER, DF.LlY) 
M::DREfS; 


RQ)\CPT: 
PROCEDURE 
(EXCHANGE$POJNTER) 
ADDRESS 
EXTERNAL; 


DECL~RE 
EXCH)\NGESPOJNTFR 
ADDRESS; 


ROIS·ND: 
PRCCEDURE 
IJEDSPTP) 
EXTERNAL; 


DECLARE 
JED$PTR 
ADDRESS; 


END 
RQISND; 
Sinclude(:ff:exch.elt) 
DfCLARE 
EXCHANGESDESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 


~SCSHEAD 
~DDREfS, 
~SGSTAJL 
~DDRESS, 
TASKSHEAD 
ADDRESS,' 


TASKST~JL 
ADDRESS, 


inter 


21 
1 
?2 
1 


23 


?l'I 
? 
25 
2 
?f1 
2 


27 


31 
2 


~3 
;> 


34 
? 


31) 
2 


27 
.., 
'- 


3P 
2 


3 S' 
2 


'1(' 
2 


L! ] 
1 


"1F.XTSEXCH 
!,PDRESf;) ,; 


~inclucp(:fr:msg.pltl 
DECL!PE 
~~G~HDR 
LTTERALLY 
, 
LINK 
JlDDPESS, 
LFNGTH 
!·.DCRESS, 
TYPE- BYTE, 
HOMESEXrHANGE 
JlDDnrSS, 
RESPCNSESEXCHANGE 
I'PDRESS'; 


DF.CL~RE 
MSGSDESCRIPTrR 
LITF.RJlLLY 'STRUCTURF( 


r~SG ,~I:'R, 
RC: 
::~_f 
II) 
FYTEl'; 


decJ?re 
t1Mex 
excrrngeSdescriptor 
extern?]; 


reclare 
rqfsrx 
exch?ngeSeescrir-tor 
extern?]; 


cqSnextSgi\le: 
procerure(queSptr,date~byt€) 
byte 
external; 
ceclare 
oueSptr 
redress; 


cpclare 
rlateShyte 
byte; 


end 
cq$nextSgive; 


This 
procedure 
is 
used 
to 
convert 
r 
rex 
byte 
into 
two 


ASCII 
characters 
anf 
store 
them 
into 
the 
next 
two 
loc- 


ations 
of 
the 
O$out 
CAte 
area. 


Declare 
(highSbyte,hexSbyte,lowSbyte,st?tus) 
byte; 


Decl?re 
q$ptr 
arldress; 


If 
(I~ighShyte:=(shr(hexSbyte,l!) 
C'no CFR) 
> 
~ 


then 
~ighSbyte 
= 
highShyte 
+ 
37H; 


else 
highSbyte 
= 
highSbyte 
+ 
3rH; 


If 
(lo\o!Sbyte:=(-hexShyte 
end 
CFH)) 
> 
~ 
then 
low$byte 
= 
lowSbyte 
+ 
27P; 
else 
lowSbyte 
= 
10wSbyte 
+ 
~0H; 


stiltus 
sti'tus 
cqSnextSgivP(.Q$0UT, 
highSbyte); 
cqSnextSgive(.Q$nUT, 
lowSbytel; 


return; 


en" 
cqShexScsc; 


end 
hexSesc$module; 


inter 


StjtIE('CHECKSU~ 
C~LCUL~Tr0N 
PROCEDURE') 
CHECKSU~S~ODULE: 
Po; 


clecli'rE'COl:1 
litf>rcJly 
'0011'; 


Sincluoe(:fl:r.ommsg.clt) 


oecl?re 
nsgSfornet 
liter01ly 
'structurE' 
( 
trgt 
byte, 
cmne 
byte, 
seqSI", 
',-tf', 
seqSn? 
byte, 
text(25r) 
byte)'; 


decl2re 
queueSformat 
Jjterelly 
'structure 
( 


endSptr 
hyte, 
giveSptr 
byte, 
t?keSptr 
bytp., 
cato"Sbytp. (254) 
bytf> )'; 


ceclere 
p2rSforM?t 
literally 
'structure 
( 


I? 
byte, 
ne 
byte, 
run 
byte, 
stop 
byte, 
queSpt 
byte) 
,; 
Sincluoe(:fr:synch.ext) 
ROSEND: 
PR0CEDURE 
(EXCHPNGESPCINTER,~ESSAGESPOINTER) 
EXTERNPL; 
DECLARE 
(EXCHPNGESPOINTER,MEfSAGE$POINTER) 
ADDRFSf; 


P0\"P IT: 
PROCEDURE 
(EXCHrNGESPOINTER,DELAY) 
ADDRESS 
EXTERNrL; 
DECLARE 
IFXCHPNGE$POJNTFR,DELPY) 
ADCRF;S; 


RorCPT: 


PROCEDURE 
(EXCHlNGE$POJNTER) 
PDDRESS 
EXTERNPL; 
DECLPRE 
EXCHPNGESPOINTFR 
ADDRESS; 


RQISt-'O: 
PROCECURE 
(IEC$PTR) 
EXTERNAL; 


DECLPRE 
IECSPTR 
PDDRESS; 


Et-1DR('ISND; 
Sinclude(:fr:f>xch.elt) 
DECLARE 
FXCHANGESDESCRJPTCR 
LITERALLY 
'STPUCTURE 
( 


MSGSHEPC 
~DDPEfS, 
~SGSTAIL 
prDRESS, 


TAEK$HEAD 
ADDRESS, 


TfSKST~JL 
frrRESS, 


inter 


31 
2 
:'l2 
2 
33 
~ 


3" 
3 


3t; 
3 
":1"' 
3 
- 
I 


3£ 
3 


NEXT$EXC~ 
ADCFESS) 
'; 
$incluoe(:fr:msq.elt) 
QF.CLARE 
~SG$HDR-LTTFR~LLY 
I 
LINK 
JlDDREf:f, 
LENGTH 
JII::DPESS, 
TYPE 
PYTE, 
HC~ESEXrH~NGE 
IODPESS, 
RESFO~fE~F.XCHANGE 
~CDRESS'; 


DECLPRE 
~SGSDF,srhIPTOR 
LITERALLY 
'STRUCTURF,( 
Tv'SCSHDR, 
REr-'l' 
HIDER (l) 
BYTE) 
I 


neclere 
timex 
exch2n~e$descrirtor 
eyternnl; 
oeclere 
rqfsrx 
excpange$cescriptor 
external; 
CQ$CHECKf:UM: 
Proceoure(qSptr) 
byte 
reentr~nt 
public; 


This 
procecure 
is 
usee 
to 
determine 
tpe 
chec~sum 
of 


a 
messege 
which 
hps 
been 
received 
pnd 
storec 
into 


the 
Q$in 
huffer. 
A checksuM 
will 
be 
celculpted 
on 
211 


cherpcters 
beginning 
at 
the 
start 
of 
text 
2nd 
continuing 
until 
the 
checksum 
bytes 
ere 
encounterec. 


This 
vp]ue 
will 
be 
testec 
with 
the 
value 
tr2nsrnitted 


enc 
if 
they?gree, 
a 
"i'1]ueof 
7.('rowill 
be 
returned 


to 
the 
calling 
progr?m. 
If 
not 
in 
i'1green0nt, 2 


non-zero 
value 
will 
he 
returned. 


Qeclare 
(ptr,enoSptr,qSptr) 
eo<"1ress; 
Decli're 
(checksn,strinoSsum,char,n) 
byte; 
DeclC're 
li'st.$cri"rs(3) byte; 


PTR 
= 
QSIN.teYe$ptr; 
ENDSPTR 
= 
QSI~.endSptr; 


cher 
= 0STN.optpShyte(ptr); 
co 
while 
char 
<> 
EOTv'; 
crecksm 
= checksm 
+ 
chAr; 
if 
Ftr 
= 
en(l$ptr 
then 
ptr 
= 
v,; 
else 
ptr 
= 
ptr 
+ 
1; 
cr co r 
= 
0 S TN. 
(l C' t C'l Shyt E' (p t r) ; 
end; 


inter 
APPENDIX 
D 


/* 
l2st 
three 
ch~r?cters 
in the 
mess~ge 
?re 


not 
inclu~e~ 
in 
the 
checksum, 
so 
they 
must 


be 
suhtr~ctec 
•••• */ 


-,C' 
2 
-'- 


l'l 
;) 


.-:7. 
;) 
t.: 
~ 


4/ 
:> 


lit; 
3 
n 
: 
4f 
2 


/* first 
remember 
the 
lest 
aueue 
loc?tion 
*/ 
if ptr 
= 
pnc~ptr 
tl'en 
("h? r 
r; 
else 
("her = 
ptr+l; 


"'0 
n = r 
to 
2j 
("hecr.sl11 
= crecl<sm - 
(li'st~ch?rs(n):= 
OSJN.c1et?~byte 
(ptr)) 
j 
if 
ptr 
= r 
then 
ptr 
else 
ptr 


enc'l; 
checksm 
= che("ksM + 
l?sttch?rs(r)j 


enr.~ptr; 
- • tr 
- I j 


4 S' 
~ 
< 
5r. 
:> 


52 
3 


5: 
: 
5t! 
2 


55 
'2 


[\0 
n 
= 
1 
to 
2; 
if 
l?st~ch?rs(n) 
> 
then 
lest~ch?rs(n) 
else 
12st~chcrs(n) 


eni1j 
string~suM 
= 
shl(1?st~ch2rs(7),") 
+ 


t.(1H 
last$ch?'rs(n) 


= l?st$cr,:ors(n) 
37Hj 


- 
:rRj 


if 
stringSsun 
= checksm 
then 
return 
0; 


57 
'2 


c:p 
;> 


c:C' 
2 
(-:(' 
1 


else 
C$TN.t?ke~ptr 
= cherj 
return-]j 


ent:'co5checksLlM; 
cnt:'checksum~moc1ulej 


~title('GENFP~TF 
PEADY 
~ES~PGF 
PROC~DURE') 
GEN~RDYS~ODULE: 
Do; 


0ecl?re 
eom 
liter?lly 
'rDH'; 


Sinclure(:fl:comMsg.clt) 
~ecl?rp 
nsg~form?t 
liter2lJy 
'structure 
( 
trgt 
byte, 
cl'1nr 
byte, 
s('qSlr> 
byte, 


seqSn? 
hyte, 
text (;:> 5(1) by te 
)'; 


rcclcrc 
queue$fornrt 
1iter?lJy 
'structure 
( 


enc$ptr 
hyt~, 


give~ptr 
byte, 
t2ke$ptr 
byte, 
clet?Sbyte (754) 
hyte 
)'; 


cleclrrc 
p?rSfor~?t 
literally 
'structure 
( 
I? 
bytf', 
no" 
I:::ytf' 


run 
byt e, 
stop 
byte, 
que~pt 
byte) 
'; 


Sinclure(:fr:synch.ext) 
ROSEND: 


PROCEDURE 
(EXCH~NGE$POINTER,M~SS~GFSPQINTER) 
EXTERN~L; 


DECLARE 
(EXCH~NGESPOINTER,~E~S~GF~POINTER) 
~DDRES~; 


RQI·JlI IT: 


PROCEDURE 
IExrH~NCE5prINTER,DEL~Y) 
ADnRE~S 
FXTERN~L; 


DECLARE 
IFXCH~NGE~POINTER,DEL~Y) 
~DDRES~; 


RQf,CPT: 


PROCEDURE 
(EXCHANGE$POINTER) 
ADDRE~S 
EXTERNAL; 
DECL~RE 
EXCH~NGESPOJNTF.R 
ADDR~Sf; 


RQISND: 


PROCEDURE 
(TFD$PTR) 
EXT~RNAL; 


DECLfRE 
IE~$PTR 
ADDRFSS; 


END 
RC'J~N[1; 


Sincludel:fO:excr.e1t) 
DECLARE 
FXCPANGESDE~CRIPTOR 
LJTFRl'LLY 
'STRUCTURE 
( 


MSGSHElID 
ADDRESS, 
~SGSTAJL 
ADDRE~S, 
TPSK$PElID 
ADDRESS, 
T~SKSTPIL 
AODRFSS, 


21 
1 
22 
1 


"'., 
L, 
_ 


24 
2 


25 
2 


2(, 
2 


27 
1 


NEXT$EXCH 
lDDRESS) 
'; 
Sinclure(:fC:msg.clt) 
DECLARE 
~EG$HDR 
LITERALLY 
, 
LINK 
ADDRESS, 
LENGTH 
I',DC'RESS, 
TYPE 
BYTE, 
HO~E~EXCHANGE 
ADDRESS, 
RESPONSESEXCH~NCE 
ADDRES~'; 


DECL1RF. ~SG$DESC~TPTr.R 
LITERALLY 
'STRVCTURE( 
r-1SC$J-lDR, 
RE~AINDER(l) 
BYTE) '; 


dec]~re 
ti~~x 
exchang~Sdescriptor 
cxt~rnal; 


ceclare 
rqfsrx 
exch?ngeS~escriptor 
pxtprn~l; 


cq~(TlsgSout: 
procedure 
(msgSsize,q~ptr,p2r~ptr,msgSptr) 
external; 
decJere 
msgSsizp 
byte; 


declare 
(qSptr,p?rSptr,msgSptr) 
<'Iclcress; 


pnd 
coSl".sg$out; 


COSGEN$RDY: 
Procedure 
(trget,msgSptr,qSptr,parSptr) 
reentr 


~nt 
public; 


This 
procedure 
'generates 
? 
"reRdy" 
MPssage 
onto 
the 


communicFtion 
network. 
The 
t<'lrgetaddress 
is 
p?ssed 


<'ISthe 
pr.rcmeter 
ir. the 
c~ll. 


On 
entry 
to ~he 
procedure: 
trget 
is ? hyte 
~hich 
contAins 
the 
address 


of 
the 
target 
node. 
msgSptr 
is <'In?ddress 
whirh 
points 
to 


the 
RAM 
work 
?rea. 
qSptr 
is ?n 
eddress 
whirh 
points 
to 
the 
output 
queue. 
parSptr 
is an 
?ddress 
which 
points 
to 


the 
communic2tion 
flags. 


Dec]?re 
tr~et 
byte; 


Declare 
rdySmsg 
structure 
TARGET 
byte, 
COMAND 
bY,te, 
SE('SLJI 
byte, 
SEQ::::Nl, 
byte 


C?t? 
( 
r,3,r,r); 


declAre 
(MsgSptr,qSptr,pRrSptr) 
ar.dress; 


inter 


24 
2 


:5 
2 
]~ 
'2 
37 
1 


return; 


enc 
('qSc:'€n~rf.y; 
enf. gen$rcyt~vcule; 


~title('DPTl 
~ESSlGE 
GENERlTOR 
PROrEDURE') 
GEN~M~($~CDULE: 
Co; 


~eclpre 
porn 
literAlly 
'rOH'; 
$include(:f]:ro~msg.clt) 


cecJAre 
MsgSformAt 
Jiterr]ly 
'structure 
trgt 
byte, 
cMnr 
eyre, 


sea$lil 
bytE', 


seq~n2 
byte, 


text (750) 
hytE' )'; 


declAre 
queueSform0t 
liter?lly 
'structure 
( 


enc$ptr 
hytr, 


giveSptr 
byte, 
tpkeSptr 
byte, 


0AtPSbyte(254) 
byte)'; 


declrre 
pAr$forM?t 
literally 
'structure 
( 
12 
byte, 
n? 
byte, 
run 
byt.e, 
stop 
byte, 
C!ue~pt 
byte) 
'; 


Sinclude(:f0:syncr.pxt) 
Fi(lSEND: 
PROCEDURE 
(EXCHlNGE$POJNTFR,~ESSlGE$POINTFR) 
EXTERNAL; 


DEr.LARE 
(EXCHANGE$POINTER,~ESSAGF.$P0JNTER) 
ADDRESS; 


RQI'!l.IT: 


PROCEDURE 
(EXCHlNGE$POTNTER,rELAY) 
lDCRESS 
FXTERNAL; 
DECLlRF 
(EXCHANGF$P0TNTER,DFLAY) 
ADORErS; 


RQI'CPT: 


PROCEDURE 
IEXCHANGE$POJNTER) 
ACDPFfS 
F,XTF,RNAL; 


DECL~RF 
ExrHANGF.$POINTER 
ACDRESf; 


PQISN[': 


PROCEDURE 
(TFD$PTR) 
EXTER~lAL; 


DECLARE 
TFD$P~R 
~DORFS;'; 


H~C 
RQTSND; 
$incluce(:fr:exch.elt) 
DECLlRE 
EXCH1NGE$DESCRIPT0R 
LTTERALLY 
'STRUCTURE 
( 
~EGSHElD 
ADDRESS, 


~SC$T1IL 
lCCRESS, 
TASKSHElD 
ADCRESS, 


TASK~TlIL 
ADCRESS, 


NEXT~EXCH 
~DDRFSS) 
'; 


~inclurlel:fr:msg.elt) 
rECL~RE 
~SG$HDR 
LITERfLLY 
, 
LINK 
ADDRF.SS, 
LEf\!GTHJlDDRESS, 
TYPE 
EYTF., 


HO~E~EXCHJlNCE 
JlDDRESS, 


RESPCNSES'EXCllJlNGF IIDDRESS'; 


DECLARE 
~scsrESCRIPTOR 
LITER~LLY 
'STRUCTUPEl 
r~SGSflDR 
, 


RE~JlH!DER(l) 
BYTE)'; 


~ec12re 
timex 
exchenge~~escrirtor 
externel; 


(ccl?re 
rqfsr~ 
exch2ngeS~€scriptor 
external; 


ccSrr.sgSout: 
procecure 
(msg$siz€,cSptr,perSptr,msgSptr) 
exterpal; 


declare 
nsgSsize 
byte; 


declare 
(o~ptr,PC'rSptr,msgSPtr) 
'i"rl~ress; 


encl cq~msg~out; 


CQSGENS~SG: 
Prooeoure 
(~sgSpointPr, 
trget, 
msgSptr, 
oSptr, 
parSptr,s?veSflg) 
reentrantpuhlic; 


This 
proce~ure 
generates 
2 oata 
message 
anc 
places 


it 
onto 
the 
system 
comnunications 
network. 


On 
entry 
to 
the 
procecure: 


msgSpointer 
is 
an 
2~dress 
which 
points 
to 


the 
~cta 
to 
he 
transmitted. 


trget 
is 
2n 
hyte 
which 
contains 
the 
address 
of 
the 
target 
node. 
msgSptr 
is 
an 
Address 
which 
points 
to 


the 
R~~ 
work 
area. 
oSptr 
is 
an 
address 
which 
points 
to 
t~e 
output 
queue. 
parSptr 
is 2n 
?~~rcss 
whic~ 
points 
to 
the 
cOMmunications 
f12g5. 


Decli"re 
(msgS'pointer,msgSptr,qSptr,parSptr,ran$si7c) 
a 


C'0 ress; 


Declare 
(trget,saveSflg) 
byte; 


Declare 
0i"taSmsg 
structure 
target 
byte, 


comi'nd 
byte, 
segSLA 
byte, 
spg$NJ' 
byte, 
text 
byte 
) 


cata 
(r,2,r,r,r); 


3P 
2 


L! C' 
3 


/.'2 
3 


43 
:' 


~4 
2 


<1 = 
2 
Llf 
J 


cec]?re 
0ct?~block 
bCise0 Msg:pointer 
structur~ 


MsgShc'r 
); 


/* Move 
message 
forMat 
into 
message 
buffer 
*/ 


('<"IJr.love 
(r?t?:hJock.Jength, 
!"1sgSpointer, 
.msg.t~xt(r 


) ; 


r?mSsize 
= ~?ta$h1ock.1ength; 


<':aI1ca$n.sg~out 
(remSsize,q!O'ptr,perSptr,msg:ptr); 


if 
sCiveSfig 


then 
('0; 
if 
ramsize 
mod 
4 
> 
r 
then 
rat?ShJock.length 
= rat?Sb10ck.Jength 
+ 
(4-(r 
2M~size 
DOC 
4)); 
Cell 
RQSEND 
(.rqfsrx, 
msgSpointer); 


end; 


return; 


end 
cqSgen$!"1sg; 


encl gen:nsg$moru1e; 


inter 


$title('iSEX 
351 COMMunic2tions 
Driver, 
Version 
1.3') 
~nointvector 
Cen51: 
Do; 


This 
nocule 
~ont~ins 
the 
physical 
interf2ce 
for 
support 
of 
tre 
Intel 
iSBX 
351 
cOMmunic2tions 
expansion 


hoard. 
The 
b02r~ 
is 
insertec 
into 
soc~et 
J~ 
an~ 
has 
a 


b?se 
2ceress 
of 
F0H 
witr 
the 
interrupt 
from 
the 


receiver 
strapped 
to 
tre 
interrupt 
level 
~. 
The 
tranSMitter 
interrupt 
is 
wirec 
to 
interrupt 
level 
C 


~uJti-crop 
communication 
opt.ions 
2re 
supportec 
by 


the 
physical 
softw2re 
p?C~agF. 


Sincluce 
(:f0:exch.elt) 
DFCL~RE 
EXCH'NGESDESCRJPTOR 
LJTER~LLY 
'STRUCTURE 
( 
~SGSHEAD 
~rCRFSS, 
~SGtT~JL 
~DDRFSS, 
TPSKSHE'D 
'DDRESS, 
T~SKST~IL 
'DDRESS, 
NEXTSEXCH 
PDDRESS) 
'; 
Sinclude 
(:f0:ieo.elt) 
rECL' RE 
JNTS EXCHflNGESDFSCRI 
PTOR 
LITER!' LLY 
'STRUCTURE 
( 


MESSAGESHEAD 
flODPESS, 
MESS~GEST"IL 
ADDRESS, 
T'SKSHE'O 
PDDRESS, 
TASKSTPIL 
,crRESS, 
EXCPl'NGFSLINK 
flDDRFSS, 
LINK 
'DORESS, 
LENGTH 
'.DDRESS, 
TYPE 
PYTEl'; 
re~l2re 
R0L(,FX 
intSex~hangeScescriptor 
external; 
Cecl2re 
POL7EX 
intSexcr2noe$cescriptor 
external; 


tincluce 
(:fl:commsg.eltl 
ceclare 
msgtformat 
literally 
'structure 
( 
trgt 
byte, 
cmnc' 
bytP, 
seo$lCl 
hyte, 
seo.~ni' 
byt.p, 
text.(25[1) 
byte)'; 


c'Fclare 
QueUeSforMat 
lit.erally 
'struct.ure 
( 
encSptr 
byte, 
giveSptr 
byt.e, 
takeSptr 
hyt.e, 


c1C't?Shyte (2511) 
bytp 
) '; 


inter 


(\ 
1 
lC 
1 
1 ] 
] 


1 :' 


]2 
2 


1 ~ 
2 


] " 
2 


] r; 


] 7 
'2 


lP 
2 
]C' 
.l 


2r 
2 
21 
2 


22 
1 


23 
2 
2t- 
2 
.,co 
2 
,. - 
2~ 
1 


2" 
'2 


2P 
2 
2S' 
] 


.?C 
2 
-" 
'2 
- ~ 
:'2 
] 


23 
2 


..•., 
;> 


")" 
;> 


-'r. 


")-, 
2 
2F 
2 


")0 
.,, 


U 
1 


ill 
2 


42 
2 


43 
2 
4t- 
1 


t!" 
2 


J? 
!:'ytp, 
n" 
hytp, 
ron 
hytf', 
stop 
byte, 
ClL1E'~pt 
bytp) 
,; 
Pecl?re 
,rrN~L 
aueup~for~rt 
cxtf'rn?l; 
Decl"re 
C00UTSL·~L1eue~forM?t 
extern?J; 
reclere,CQPlRS 
r"r~forn?t 
externr]; 


SincJude 
(:fl:conc0~.cyt) 
CQSr-1EXTSGrVF: 
Procee'ure 
(aSptr,giveShytP) 
hyte 
0xterri'lJ; 
recJ?re 
~Spt.r ~rrress; 
00cl?re 
giveShyte 
rytf'; 
~nr 
cqSnextSgive; 
CrSTl<KESTEST: 
Procedure 
(gSptr) 
byt.p extern"'J; 
Decli'lre a$ptr 
?ceress; 


end 
cqSt?Ke$test.; 
CCSNEXTST!,KE: 
Procf'du re 
(qSpt r) 
byte 
extern<' l; 
Declare 
gSptr 
?de'ress; 
end 
cqSnextSt.?~e; 
CQS(1SINIT: 
Procec'ure 
(qSrtr,aSsize) 
€xtf'rni'lJ; 
Declare 
qSptr 
?reress; 
Decl?re 
qSsize 
byte; 
end 
caSqSinit; 
CQSl<SCSHEX: 
. 


Procedure 
(qSptr,l'1sgSptr) 
pxtern",]; 
Dpc]are 
(qSptr,msgSptr) 
?ddress; 


enr 
caSc'scShex; 
CC't:CHECK~UM: 


. 
Procec'urf' (qSptr) 
byte 
extern?J; 


Decli'lre qSptr 
?c'err-ss; 


end 
caSchf'c~sum; 
C('SHEX$lISC: 
ProcN'ure 
(qSptr,hexShyt.r) 
f'xtern<'l; 
DecJi'lrf'aSptr 
<,c'c'ress; 


P0c]"rc 
rcxShytc 
hyte; 


ene' ccSbexS?sc; 
,QSt"f'CS0lJT: 
Procec'ure 
(nsgSsi7e,QSrtr.perSptr,l'1sqSptr) 
pxt0rn2J; 


rcc12rp 
nsqSsizc 
hytE; 
rpc12rc 
(aSptr,f<"rSrtr,l'1Sc:ptr) 
2c'c'ress; 


cne' 
ccSnsgSout; 
C(iSC £t'S RCY: 
Procer'u rE' (trgpt ,ms(l~pt r ,oSptr, p? rSptr) 
('xtern? 1; 


PecJarr 
trget 
hytp; 
rf'clC're (l'1sgSptr.aSptr.p;'rSptr) 
rc'e'ress; 
,nd 
cqfgentrcy; 
COSGENSfv1SC: 
Praccc'urp 
(nsg~pointpr,trget.nsgSr~i,cSptr,p?rSptr,s?v 


('SfJq) extern?l; 
J)f.,cl?[f'(tCget .sC'\,pSfJa) 
hytp; 


inter 


~pcl?r0 
(msq~poi~t~r,Msg~ptr,qSptr,p?rtptr) 
?cc.rrss; 


~nc' CQ~g('ntMsg; 
Sincluc.e 
(:fr:synch.pxt) 
RO:-EN[': 
PRCCEDURE 
(EXCHlNGESPOINTrR,~E;.r~GFtPoINTER) 
EXTERNfL; 


DECL~RE 
(EKCH~NCF~POINTFR,~EfS~GF~POINTFR) 
ADDRFSS; 


PQ\"~ IT: 
PROCEDURE 
(F:XCH1\NGF$POINTER,DEL1Y) 
~rDRESS 
FXTERNJlL; 
CECLJlRE 
(EXCH~NGFSPOINTER,rELJlY) 
~DCRESr; 


R(1l'CPT: 
PR0CF:CUPF 
(EXCHANGF~POINTER) 
JlDDRESF 
EXTERN~L; 
DFCLl'RF 
FXCHANGE$POINTFR 
JlDDREFS; 


RC'I 9'I': 
PROCEDURE 
(TED$PTR) 
EXTERN~L; 


DECL~RE 
IFDSP7R 
~nDRESS; 


ENIC RQISNIC; 
$incluc'e 
(:fr:intrpt.~xt) 
ReENOI: 
FROCEDURE 
EXTERN~L; 


R('ELVL: 
PROCEDURE 
(LEVEL) 
FX7ERNJlL; 
[lECL~RE 
LEVEL 
PYTEl 


RQDLVL: 
PRCCEDURE 
(LEVEL) 
EXTERNJlL: 
nECL~PE 
LEVEL 
BYTE; 


RQSETV: 
PROCEDURE 
(PROC,LEVEL) 
EXTFRNJlL; 


rFCL~RE 
PRoe 
JlDDPESS; 


DECL~RF 
LF:VEL PYTP; 


PQSETP: 
FROCFDURF 
(PROC,LEVEL) 
FXTERNJlL; 


DECL!'RE 
PRne 
JlDCRESS; 


DFCLJlRF 
LFVEL 
PYTF.; 


inter 


p;> 
1 


p" 
2 


8" 
2 
1'5 
2 
Pr, 
::' 


87 
2 
8(' 
'2 
P9 
2 
Sf' 
2 


S'1 
;:> 


0'"' 
2 
_' 
I: 


9:: 
2 
9~ 
2 


95 
2 


gh 
2 


~; 
..,;. 


Df'clClrf'EO/" 
liter?lly 
'rDH'; 
/* defines 
eno 
of 
Mf'ss?ge 
*/ 
Decl?re 
PTS 
liter?lly 
'rrJrrrrrb'; 
/* reedy 
to 
send 
to 
US~PT 
*/ 
Dpcl?re 
RXE 
liter?lly 
'prrrrlrrb'; 
/* 
ready 
to 
rec~ive 
to 
USART 
*/ 
Decl?re 
DTR 
liter?lJy 
'rrr(lr01rb'; 
/* d?ta 
Sf't 
reaey 
to 
US~RT 
*/ 
DeclC're 
TXF~ 
literally 
'(lr.r0rrrl~'; 
/* tr?ns~it 
enable 
to 
Uf~RT 
*/ 
Leclere 
hadint 
hyte; 
/* flag 
for 
interrupt 
5 
*/ 


~eject 
/********************************************************* 


This 
procedure 
initializes 
the 
r?rdw?re 
required 
to 


operate 
the 
iSFX 
]51 
expansion 
board. 


C0$INI'I'~35J 
: 
Procedure 
~ublic; 
Declare 
n 
byte; 


/* initi~lize 
the 
timer/counters 
*/ 
output(rfbr) 
rbGh; 
/* select 
counter 
2 */ 


output(rf?t~) 
:'l2; 
/* 
Ish 
for 
2l1rC h?uc1 */ 


output 
(rfC'h) 
0; 
/* 
Msb 
for 
;:>4"r. 
hAud 
*/ 


/* initialize 
the 
USlRT 
*/ 
output 
«(1flh) 
Pr-H; 
output(Cflh) 
r; 
output(rflr.) 
trh; 
output 
«'flr:) 
rcrt~; 
op 
*/ 
output 
(rflh) 
20r; 


/* cJear 
out 
garb?ae 
*/ 


/* •.. More 
g2rbage 
*/ 


/* reset 
the 
US~RT 
*/ 


/* 
P hit, 
no 
r?rity, 
;1 
st 


C~LL 
rqsetv(.cqMivt~3~1, 
~); 
Cell 
rosp.tv(.senctchC1r~:5], 
5); 
call 
rqE'lvl 
( 
5); 
c?ll 
rqelvl ('1); 
return; 


ene 
cqSinitS'Sl; 
Seject 
/********************************************************* 


This 
procedurE' 
stores? 
character 
from 
the 
USfRT 
into 


the 
receiver 
cat? 
input 
queue. 


inter 


SF 


9 ~\ 
2 


lC'C' 
2 
HJ 
2 
lr2 
;> 


HL: 
2 


lC'~ 
2 


HI 
2 


IH 
3 


J 11' 
" 
1J 3 
t 
11 t 
t 


115 
3 


117 
" 
lH 
t1 
1 19 
~ 
12[' 
" 
In 
L1 


17? 
11 


12~ 
3 
17" 
t: 


J2~ 
t 


12 r; 
5 
12"' 
I! 


l/f 
.:: 


C'Or-"IVT$351: 


Procecure 
interrupt 
(, public; 


Cec)?re 
(GIVE$rTlTUS,CH~R) 
hyte; 


/* get 
ch?r?cter 
from 
US~RT 
*/ 


ch?r 
= 
inrut(C'FOh) 
?nc 
C7Fr; 


giveSstatus 
= cqSnpxt~give(.cqinsl, 
ch?r); 
if 
chrr 
= 
('om 


t~en 
c?ll 
rqisnd(.rol~ex); 


else 
coll 
rqenci; 


ene' cqmivtS351; 
Seject 
/********************************************************* 
This 
procedure 
sene's out 
tre 
np.xt cr?r?cter 
to 
the 


selectee' 
US~RT 
device. 
It will 
c'isrbl(' the 
interrupt 
when 
?11 desired 
ch?racters 
rrve 
been 
transmitted. 


********************************************************/ 
f. ENDS CHMl $3 51 : 
Proce~ure 
interrupt 
5 public; 


Declare 
chrr 
hyte; 


/* en?b1e 
orivers 
at 
beginning 
of 
~ess?ge 
*/ 
If 
not 
cop?rs.run 
then 
e'o; 
cap?rs.run 
= 
J; 
co pc rs ._stop = 
('; 


eno; 


/* c'is?ble 
e'rivers 
?t 
end 
of 
message 
If 
cqp?rs.stop 


tren 
00; 


cqpi'rs.run 
= 
C'; 


Do 
while 
(inpuUC'FJh) 
ene' 
11) 


eno; 
b?e'int = r; 
output(rFJr) 


ene'; 


/* if 
~essage 
is 
in 
rrogress, 
sene' n0xt 
ch?r?cter 
*/ 


else 
~o; 
ch?r 
= cqSnextSt?~e(.cqouts1); 
c' 0 
~;hi 1e 
Ii n rut (r f J h) 
il n c' 
<1) 
= r; 


enc; 
output 
(OFr-r) = chrr; 


/* 
test 
for 
en0 
of 
m0SS?Oe 
*/ 


if 
(cr?r 
rnr 
0fr.) = 
com 


1:;r 
t; 


131 
4 
17.2 
:: 


132 
') 


121' 
') 


1:'~, 
;> 


L'" 
1 


1"'" 
') 


13f 
2 


J :' () 
2 


Ur: 
2 


10 
1 


tben 
~qp2rs.stop 
J; 
else 
CC~nrs.stop 
r; 


f'n(l; 
ene'; 


/* 
rf'-en2ble 
interrupts 
*/ 


ci111 
raenfi; 


en~ 
sen~tcbFrt351; 
~E:ject 
/********************************************************* 


********************************************************/ 
CO~ST~RT~MSGt351: 
Procedure 
public; 


bi'c1int = 
L'ffh; 
output(CFlh) 
75h; 


rfCturn; 
ene' cq~start~nsgS35J; 


inter 
APPLICATION 
NOTE 


An application 
system based on a custom hardware 


design will typically perform 
faster and require less 


hardware than if it were implemented with "off 
the 


shelf" circuit boards. 
However, these advantages are 


countered by the disadvantages of custom designs, with 
one of the largest drawbacks being the custom software 
required. This software is often unique to the applica- 
tion and specific to the hardware design, requiring a 
significant and increasing percentage of the develop- 
ment schedule and expense: The cost is multiplied by the 
need for software tools, standards, 
and maintenance 


developed specifically for each application. In addition, 
much of the application 
software cannot be used for 


new applications or hardware. 
All of these disadvan- 


tages can be significantly reduced by using a modular, 
standardized operating system. 


The operating system provides a higher level interface to 
the system hardware. The hardware characteristics com- 
mon to most applications, such as memory management 
and interrupt 
handling, are handled by the operating 


system 
rather 
than 
the 
application 
software. 
The 


operating system provides scheduling and synchroniza- 
tion for multiple functions, allowing application code to 
be written 
in independent 
pieces or modules. 
The 


operating 
system interface can be more standardized 


then the interf/lce to the hardware components. 
This 


allows the application software to be more independent 
of changing hardware. The application code can 'be in- 
itially implemented and debugged on proven hardware. 
The software is then easily moved to the fmal hardware 
configuration 
for testing. 


8284 
CLOCK 
GENERATOR 


The operating system interfaces allow the use of stan- 
dard software tools, such as debuggers. Operating sys- 
tems also provide decreased debugging time and in- 
creased reliability through 
error checking and error 


handling. Perhaps most important, the expertise gained 
can be carried on to new designs based on the operating 
system. 


Operating 
systems have generally been described as 


large and complex, with rigid system requirements. 
Users have found it difficult to tailor a system to their 
needs or to use the operating system on more than one 
hardware configuration. 
System software has been ac- 


cepted in large pieces or as a whole, with few system 
configuration 
choices in either hardware or software. 


Those systems small enough to use on component de- 
signs have lacked extendibility to larger, more complex 
designs. 


The Intel iRMX 86 Operating System offers users of 
component hardware all benefits of operating systems 
while imposing few hardware 
restrictions. 
Minimum 


hardware 
requirements 
include I.8K RAM memory, 


enough RAM or EPROM memory to hold the Nucleus 
and the application code, and a handful of integrated 
circuits. The circuits are an Intel iAPX 86 or iAPX 88 
Central Processing Unit, an Intel 8284 Clock Generator, 
Intel 8282/83 Latches for bus address lines, an Intel 
8253 Programmable Interval Timer, and an Intel 8259A 
Programmable 
Interrupt 
Controller. 
Larger 
system 


busses will also require an Intel 8288 Bus Controller and 
Intel 8286/87 Transceivers 
for data lines. This basic 


hardware system is shown in Figure I. 


intel 


Users with a wide range of applications will find the 
iRMX 86 Operating System allows them to implement a 
corresponding range of capabilities, from a minimum 
iRMX 86 Nucleus to a high level human interface. A 
complete iRMX 86 Operating System includes extensive 
I/O capabilities, 
debugger, application 
loader, 
boot- 
strap loader, and integrated user functions. This flexi- 
bility allows one operating system to be used for many 
projects, minimizing software learning curves for new 
applications. 


This note discusses a relatively small standalone spec- 
trum analysis system based on a subset of the iRMX 86 
Nucleus. The intent of the note is to demonstrate advan- 
tages of using operating systems in hardware compo- 
nent designs. An overview of operating system func- 
tions is given first as background information. 
Readers 
familiar with operating systems may wish to skip this 
section. The overview is followed by a summary of the 
iRMX 86 Operating System. The summary is brief, as 
only the iRMX 86 Nucleus is used in this application. A 
detailed discussion may be found in Application Note 
AP-86, "Using the iRMX 86 Operating System," and 
iRMX 86 System Manuals. 


The spectrum analysis system is described after the sum- 
mary. The system requirements, design and implemen- 
tation are detailed. The system software is discussed 
next, followed by configuration 
and hardware imple- 


mentation. A summary completes the application note 
text. Partial code listings of the system software are in- 
cluded in the appendices. 


OPERATING 
SYSTEMS FUNCTIONAL 


OVERVIEW 


Operating 
system 
software 
manage 
initialization, 


resources, scheduling, synchronization, 
and protection 


of tasks or functions within the system, as well as pro- 
viding 
facilities 
for 
maintenance, 
debugging, 
and 


growth. In general, operating systems support many of 
the following: 


Multiprogramming 


Multiprogramming 
provides the capability for two or 


more programs 
to share the system hardware, 
after 


being 
developed 
and 
implemented 
independently. 
Within the environment 
of an operating system, the 


programs are called jobs. Jobs include system resources, 
such as memory, in addition 
to the actual program 


code. Multiprogramming 
allows jobs that are required 


only during development, such as debuggers, to run in 
the target system. When development 
is completed, 


these jobs are removed from the final system without af- 
fecting the integrity of the remaining jobs. 


Multitasking 


Multitasking allows functions within a job to be han- 
dled by separate tasks. This is particularly 
valuable 


when a job is responsible for multiple asynchronous 
events or activities. One task can be assigned to each 
event or activity. Tasks are the functional members of 
the system, executing within the bounds of a job en- 
vironment. Program code for a multitasking system is 
modular, with well-defined interfaces and communica- 
tion protocols. The modular boundaries 
serve several 


important purposes. The code for each module can be 
generated and tested independent of the other modules. 
In addition, 
the boundaries 
confine errors, 
speeding 


debugging and simplifying maintenance. 


The modular independence that results from multipro- 
gramming and multitasking gives users the ability to ef- 
ficiently create new applications by adding functions to 
old software. Applications can be tailored to specific 
needs by integrating 
new modules 
with previously- 


written general support code. If care is taken in system 
design, functions can be added in the field. Documenta- 
tion for the older software can be carried on to the new 
applications. This growth path will save completely re- 
writing expensive custom software for each new applica- 
tion. 


Scheduling 


Even though a system has multiple jobs and tasks, only 
one task is actually running on the central processor at 
any single point in time. Scheduling provides a means of 
predicting and controlling the selection of the running 
task from the tasks that are ready to run. Basic sched- 
uling methods 
include preemptive 
priority, 
non-pre- 


emptive priority, 
time-slice, and round-robin. 
Batch 
systems often use non-preemptive priority scheduling, 
in which the highest priority job gets control of the cen- 
tral 
processor 
and runs to completion. 
Preemptive 


scheduling is typically used in real-time or event-driven 
systems, where dedicated, quick response is the main 
concern. A higher-priority 
waiting task that becomes 


ready to run will preempt the lower-priority running 
task. Priority may be either set at task creation (static) 
or modified during running of the task (dynamic). 


Time-slice and 
round-robin 
scheduling 
are used in 


multiuser or multitask 
systems that share processing 


resources and have limits on maximum execution time. 
Time-slice scheduling gives each task or job a fixed slice 
of dedicated processor time. Round-robin 
gives each 


task or job a turn at using the processor. The time avail- 
able during the turn depends on system load and task 
priority. 


inter 


Communication 
and Synchronization 


Jobs and tasks in a multiprogramming and multitasking 
environment require a structured means of communica- 
tion. This communication 
may be necessary to syn- 
chronize processes or to pass data between processes. 
Two means of providing communication are mailboxes 
and semaphores. Mailboxes are an exchange place for 
system messages. The messages may include data or 
provide access to other system objects, including other 
mailboxes. Tasks can send objects to a mailbox or wait 
for objects from a mailbox. Generally, the task has the 
option of waiting for a specified period of time for the 
message. The wait time may range from zero for a task 
that requires immediate response to infinite time for a 
task that must have a message to continue processing. 
Multiple mailboxes are used to synchronize multiple 
tasks. 


A communication flow using mailboxes is shown in Fig- 
ure 2. In this example, the sending task sends a message 
to a mailbox and specifies a return mailbox. The send- 
ing task then waits at the return mailbox. The receiving 
task obtains the message from the sending mailbox and 
sends a message to the return mailbox. The first task 
obtains the second message from the return mailbox, 
synchronizing 
the 
two 
tasks 
and 
passing 
data. 


Figure 
2. Intertask 
Communications 
with 
Mailboxes 


If process synchronization is the only requirement, sem- 
aphores may be used. Semaphores function like mail- 
boxes except that no data is passed through the sema- 
phore. Instead, semaphores contain "units," 
with the 


meaning of the units defined by the sending and receiv- 
ing tasks. A one unit semaphore may be used as a flag to 
synchronize the tasks. Multiple unit semaphores can be 
used for resource control. For example, if tasks require 
reusable data buffers, a semaphore may be defined as 
the allocator of the available data buffers. Each unit in 
the semaphore 
will represent 
one available 
buffer. 


When a task requires buffers to continue, the task will 
wait at the semaphore until enough units (representing 


buffers) are available. The waiting task will receive the 
units, 
use the 
buffers, 
and 
return 
the 
units 
(still 


representing buffers) to the semaphore. Other tasks that 
require buffers will also have to wait at the semaphore 
until enough buffers are available. 


The operating system is the central guardian of system 
resources, specifically read/write memory. The memory 
is made known to the Nucleus at initialization. 
The 


Nucleus then gives pieces or segments of the memory to 
tasks as they request it. This allows the tasks to have no 
initial knowledge of the actual location and size of sys- 
tem memory. Tasks can share memory if they desire, 
but the Nucleus allocates memory to each task individ- 
ually, preventing the tasks from using each others mem- 
ory. In addition, tasks return memory to the Nucleus 
when they are through with it, allowing memory to be 
reused. 


Other system resources, such as I/O devices, will also be 
scheduled by the operating system. The operating sys- 
tem is responsible both for the efficient use of these 
resources and for providing the tasks with a large mea- 
sure of independence from the actual I/O hardware re- 
quirements. The system may require many types of I/O 
devices, such as disk drives, tape drives, and printers. 
1/0 
is more efficiently accomplished if the operating 
system provides both asynchronous 
and synchronous 


I/O operations. 
Synchronous operations are those the 


task starts and waits for completion, 
doing no other 


work until the I/O is complete. Asynchronous opera- 
tions are started by the task, but the actual I/O can take 
place while the task is doing other work. The overlapped 
operation of asynchronous I/O provides more user con- 
trol of the I/O operation at the expense of a more com- 
plicated user interface. 


Interrupt Management 


Real-time software is tightly coupled to hardware func- 
tions by interrupts. Interrupts provide rapid notification 
that the hardware needs attention. 
The software must 


respond quickly without corrupting the system environ- 
ment. System integrity is preserved by preempting the 
lower priority operating task, saving the task environ- 
ment, processing the interrupt (including communicat- 
ing the results to other tasks if necessary), restoring the 
environment of the operating task, and continuing. All 
of this must occur in an orderly and efficient manner. 
The interrupt management of the operating system is 
responsible for directly interacting with the system hard- 
ware that detects interrupts. The interrupt tasks can be 
ignorant of the detailed interrupt hardware, providing 
only the system actions to service the event that caused 
the interrupt. 


Operating systems create and manage jobs and tasks at 
initialization as well as run time. Initialization generally 
must be done in a specific sequence which will depend 
on the environment existing at that time. An abortive in- 
itialization environment 
may require an orderly shut- 
down of the system. The operating 
system has the 
capability for managing these situations, including com- 
munications, 
access to system' resource information, 


and displaying status of the initialization actions. 


The system debugger is a window into the internal struc- 
tures of the operating 
system. Debuggers allow data 


structures and memory to be examined, breakpoints to 
be set, and the user to be notified of abnormal condi- 
tions. The debugger may have symbolic debugging, in 
which system objects such as addresses, tasks, jobs, 
mailboxes, 
and 
memory 
locations 
can be assigned 


names. This gives greater flexibility and accuracy during 
debugging. The debugger may not be necessary in the 
final system, so the debugger is often a separate system 
job. This allows removal of the debugger with no effect 
on the remaining jobs. 


Debugging will be aided if the operating system verifies 
the parameters required by system actions and also re- 
turns status for the requested action. Parameter verifi- 
cation is particularly valuable for new program code in 
a developing system. Status results other than success 
are abnormal or exception conditions. Exception condi- 
tions may include insufficient memory for the request, 
invalid input data, inoperative I/O devices, an invalid 
request for an action, or a request for an invalid action. 
The operating system may have an exception handler 
for these conditions and may allow the debugger to be 
used as the exception handler. The development process 
will be more efficient if detection of exception condi- 
tions takes place for all levels of system actions, from 
initialization of jobs and tasks to requests for memory 
or status. 


With the continuing 
increase in system complexity, 
more operating systems are providing higher level func-. 
tions. These functions may include advanced I/O file 
management, 
operator 
console, 
spooling operations, 


telecommunications support, multiuser support and ac- 
cess to system resources of increasing size and complex- 
ity. Only the largest operating systems provide all of 
these capabilities, 
but users of component 
hardware 
must be careful their system will integrate higher level 
functions that may be required in future applications. 


In order to provide general purpose support, operating 
systems must be extendible. New applications may re- 
quire data structures or system actions not available 
with the present operating system. The system must be 
able to integrate these new structures and actions, sup- 
porting them in the same manner as existing functions. 
Choosing an operating system requires a large commit- 
ment, both in initial expense and system architecture. 
Extendibility provides assurance the operating system 
chosen will not provide built-in obsolescence of that 
commitment. 


iRMX 
86™ 
OPERATING 
SYSTEM 
ARCH ITECTU RE 


Layers 


The iRMX 86 Operating System architecture is shown in 
Figure 3. It includes the Nucleus, Basic I/O System, Ex- 
tended I/O System, Applications Loader, and Human 
Interface. These major portions of the operating system 
are designed as layers. Each layer may be added to 
previous layers as application needs grow. Lower layers 
may be used without upper layers. All layers may reside 
in programmable read only memory. Applications have 
access to all portions of the system, from the Nucleus to 
all outer layers. 


Figure 3. Architecture 
of the iRMX 86™ 
Operating System 


The Nucleus is the heart of the system. It includes sup- 
port for multiprogramming, 
multitasking, communica- 


tions, synchronization, 
scheduling, 
resource manage- 


ment, extendibility, interrupt handling, and error detec- 
tion. The Nucleus may be considered as an extended 
layer of the underlying hardware, giving the hardware 
system management functions and making the software 
independent of the detailed hardware. The system en- 
vironment, 
including resources, priorities, 
and place- 


ment of program code, is made known to the Nucleus at 
system initialization. 
All requests for memorY, com- 


munication, and creation of basic data structures must 


inter 


go through the Nucleus. These requests are made by 
system calls, which are comparable to subroutine calls 
for system actions. 


All higher level functions of the iRMX 86 Operating 
System are built around a core of the Nucleus. Although 
outer layers may require a substantial number of the 
system functions included in the Nucleus, the Nucleus 
itself is configurable on a call-by-call basis. "Configu- 
rable" means the Nucleus may be altered so it contains 
code only for those functions required by the applica- 
tion. Certain features, such as parameter validation and 
exception handling, are also configurable. Features and 
system calls may be included for development and ex- 
cluded from the final system, giving a Nucleus tailored 
for each level of application development. 


The Basic I/O 
System is the first layer above th~ 
Nucleus. The Basic I/O System provides asynchronous 
I/O support and format independent manipulation 
of 
data. 
Multiple 
file types 
are 
supported, 
including 


Stream, Named, and Physical files. Stream files are in- 
ternal files for transferring large amounts of data be- 
tween jobs or tasks. Named files include data files of 
varying sizes and directories for those files. Named files 
are designed for random access disk storage. Physical 
files consider the entire device to be one file. Physical 
files are primarily used to transfer data to and from 
printers, tape drivers, and terminals. Device drivers for 
both 
floppy and hard disks are provided. 
Like the 


Nucleus, the Basic I/O System provides system calls to 
invoke I/O actions. These calls and the features of the 
Basic I/O System are fully configurable. 


The Application 
Loader provides the ability to load 


code and data from mass storage devices into system 
RAM memory. The Application Loader resides on the 
Basic I/O 
System, allowing application 
code to be 


loaded from any random access device supported by the 
Basic I/O System. Application code can be loaded and 
executed as needed rather than residing in dedicated 
system memory. 


The Extended I/O System supports synchronous I/O, 
automatic buffering, and logical names. Synchronous 
I/O provides a simplified user interface for I/O actions. 
Automatic buffering improves I/O efficiency by over- 
lapping I/O and application operations wherever possi- 
ble. Logical name support allows applications to access 
files with a user-selected name, aiding I/O device inde- 
pendence. 


The Human Interface uses all lower layers, forming a 
high level man-machine interface for user program in- 
vocation, 
command 
parsing, 
and 
file utilities. 
The 


primary purpose of the Human Interface is to support 
the addition of interactive commands. The Human In- 
terface is the basis for pass-through 
language support 


and multiple user systems. 


Conflgurabillty 


Configurability means the iRMX 86 Operating System 
can be changed to include only the system calls and 
features pertinent 
to the system under development. 


Smaller applications 
start 
with only the iRMX 
86 


Nucleus. A subset of Nucleus calls, described later in 
this application note, provide the basis for management 
of jobs, tasks, memory, interrupts, communication and 
synchronization, and support for the Debugger and Ter: 
minal Handler. 


All systems calls may also use parameter validation as a 
configuration option. Parameter validation verifies that 
system calls reference correct system objects before the 
requested action is performed. During debugging and in 
hostile environments, 
validation provides error detec- 


tion for each system call. This error detection does add 
some overhead to the calls. Debugged application jobs 
can perform more efficiently without the validation, 
while new code can use parameter validation to speed 
development. 


Once errors are detected, there are two means available 
to handle error recovery. The task can either use the 
status information to perform error recovery actions or 
the recovery actions may be performed by a specialized 
errOl handling program 
called an exception handler. 


Applications 
may use the Debugger as an exception 


handler, 
or use one implemented by the application. 


There are two classes of errors that may cause control to 
be given to an exception handler; avoidable errors, such 
as programmer errors, and unavoidable errors, such as 
insufficient memory. Exception handlers can be selected 
to receive control for either or both classes. 


Support Functions 


The iRMX 86 Operating System includes a Debugger, a 
Terminal Handler, 
a Bootstrap 
Loader, and a Patch 


Facility. The Debugger examines system objects, using 
execution 
and 
exchange 
(mailbox 
and 
semaphore) 


breakpoints, 
symbolic debugging, and exception han- 


dling. The Terminal Handler provides a line-editing, 
mailbox-driven 
CRT communications 
capability. 
The 


Bootstrap 
Loader is a fully configurable 
loader 
for 


bootstrap loading on reset or command, from any spe- 
cific random access device. The Patch Facility gives the 
capability of patching iRMX 86 Object Code in the 
field. 


Object Orientation 


The iRMX 86 Operating System is based on a set of sys- 
tem data structures called objects. These objects include 
jobs, 
tasks, 
mailboxes, 
semaphores, 
segments, 
and 


regions. Users may also define application-specific ob- 
jects. Object architecture 
includes the objects, 
their 


parameters, and the functions allowed with the objects. 


Object orientation is a formal, hardware-independent 
definition of hardware-dependent 
system structures that 


are currently used by most applications. For example, 
without object orientation, 
memory is reserved in ad- 
vance for system buffers. The application code knows 
buffer sizes and locations. If buffer requirements grow, 
requiring a new memory layout, much of the applica- 
tion code will change to accommodate the new buffer 
sizes and locations. Using object orientation, 
the ap- 


plication requests a segment (buffer) of a particular size 
when the buffer is needed. The Nucleus allocates the 
memory and returns a segment object to the applica- 
tion. If the application needs a larger buffer, it returns 
the old segment and requests a new one of a larger size. 
The application 
obtains more buffers by making re- 


quests for more segments. If the hardware changes, the 
iRMX 86 Operating 
System is made aware of the 


changes. The application 
code uses the same system 


calls 
to 
request 
and 
return 
the 
segment 
objects 
regardless of the hardware configuration. 


Objects are provided for modular environments (jobs), 
application 
code 
functions 
(tasks), 
communication 


(mailboxes), 
synchronization 
(semaphores), 
memory 
(segments), and mutual exclusion (regions). Objects are 
fundamentally a set of standard interfaces between ap- 
plication code and the iRMX 86 Operating System. The 
standard interfaces have three primary benefits: 


I) First, objects provide structures, such as tasks or seg- 
ments, that are common to all applications. 
The 


structures form the basis for a standard set of system 
calls that make the interface between the application 
and the operating system more consistent and easier 
to learn. These calls allow applications to create more 
objects (segments for buffers, for example), delete 
them, change them, and inspect them. Development 
engineers can use their knowledge of the objects on 
many applications, 
rather than just the one under 


development. The common objects allow a common 
system debugger to be used. The debugger will work 
for all applications, 
letting engineers concentrate 


their efforts 
on the application 
itself rather than 


designing and implementing custom debugging tools. 


2) Second, the standard 
characteristics 
of the object 


allow consistent error detection and handling. Re- 
quests to alter or use objects can be checked for 
validity before the Nucleus actually performs the re- 
quest. Errors can be classed as common to all objects 
or specific to certain objects, giving more precise 
error information 
for effective error handling and 


faster debugging. 


3) Third, the object interface will be preserved on future 


releases of the iRMX 86 Operating System. Current 
application 
code 
can 
be split 
into 
independent 


modules. Future applications can use the modules for 


common functions, preserving the investment in ap- 
plication software. 


Task Scheduling 


The Nucleus controls task scheduling by task priority 
and task state. Task priority is specified when the task is 
created. The priority can be altered dynamically. Tasks 
are classified into one of five classes: Running, Ready, 
Asleep, Suspended, or Asleep-Suspended. 
Tasks that 


have not been created are considered to be non-existent. 
The State Transition Diagram is shown in Figure 4. 


Only one task is in the Running state. This task has con- 
trol of the central processor. The Ready state is occu- 
pied by those tasks that are ready to run but have lower 
priority than the Running task. The Asleep state is occu- 
pied by tasks waiting for a message, semaphore units, 
availability of a requested resource, an interrupt, or for 
a requested amount of time to elapse. A task can specify 
the amount of time it will allow itself to spend in the 
Asleep state, but tasks in the Suspended state must be 
"resumed" 
by other tasks. The Suspended state is use- 


ful when situations require firm scheduling beyond the 
control provided by priority and system resource avail- 
ability. Examples of these situations are system emer- 
gencies, controlling tasks in the Ready state for applica- 
tion-dependent 
scheduling algorithms, 
and guarantee- 


ing a fixed initialization 
or shut-down 
sequence. 
If 


another task "suspends" 
a task already in the Asleep 


state, the sleeping task goes to the Asleep-Suspended 
state. This task will enter the Suspended state if the 
sleep-causing condition is satisfied. The task will go to 
the Asleep state from the Asleep-Suspended state if it is 
resumed before the sleep-causing condition is removed. 
If a task enters the Ready state and has higher priority 
than the present Running task, the Ready task is given 
control of the CPU. Control is transferred to another 
task only when: 


I) The Running task makes a request that cannot im- 


. mediately be filled. The Running task is moved to the 


inter 


Asleep state. The highest-priority 
Ready task be- 


comes the Running task. 


2) An interrupt occurs, causing a higher-priority task to 


become Ready. The current Running task goes to the 
Ready state, 
allowing the higher-priority 
task to 


become the Running task. 


3) The Running task causes a higher-priority 
task to 


become Ready by releasing the resource for which the 
higher-priority task is waiting. The current Running 
task goes to the Ready state. The higher-priority task 
becomes the Running task. 


4) The Running task causes a higher-priority 
task to 


become Ready by sending a message or semaphore 
units to the mailbox or semaphore where the higher- 
priority task is waiting. The Running task is moved 
to the Ready state. The higher-priority task becomes 
the new Running task. 


5) The Running task removes a higher-priority 
task 


from the Suspended state by "resuming" 
it, placing 


the higher-priority task in the Ready state. The cur- 
rent Running task is moved to the Ready state and 
the higher-priority Ready task becomes the new Run- 
ning task. 


6) The Running task creates a higher-priority task. The 


new task goes to the Ready state. The current Run- 
ning task is moved to the Ready state and the higher- 
priority Ready task becomes t~e new Running task. 


7) The Running task places itself in the SlIspended state. 
The highest-priority 
Ready task becomes the new 


Running task. 


8) The Running task places itself in the Asleep state. 
The highest-priority 
Ready task becomes the new 


Running Task. 


9) The Running 
task 
deletes itself, pecoming 
Non- 
existent. The highest-priority Ready task will be the 
new Running task. 


System Hardware Requirements 


The iRMX 86 Operating System will run on any system 
that meets the following minimum hardware require- 
ments: 


1) An iAPX 86 or iAPX 88 Central Processing Unit. 


2) An Intel 8253 Programmable 
Interval Timer to pro- 
vide the system clock. 


3) An Intel 8259A Programmable Interrupt Controller. 


4) Enough hardware to provide a system clock and bus 
interfaces. This may be supplied by the Intel 8284 
Clock Generator, 
Intel 8288 Bus Controller, 
Intel 


8282/8283 Latches, and Intel 8286/8287 Transceiv- 
ers. 


5) The following RAM: 


a. 1024 bytes from 0 to 1024 for software interrupt 


pointers (the interrupt vector). 


b. 800 bytes for Nucleus data. 


c. Enough RAM for the application data, code, and 


system objects. 


6) Enough EPROM or RAM to hold the required parts 


of the iRMX 86 Operating System and the applica- 
tion code. 


The Intel iSBC 86/12A Single Board Computer more 
than meets these minimum requirements. A block dia- 
gram of the board is shown in Figure 5. Note in addition 
to the timer and interrupt controller the board contains 
an 82511\ USART, an 8255 parallel I/O interface, a 
MULTIBUSTM interface, 
four sockets for up to 16K 


bytes of EPROM, and 32K bytes of dual-ported RAM. 
Even though a user may be developing a custom board 
for his application, it is recommended that initial system 
development be accomplished using the iSBC 86/12A 
Single Board Computer. 
This will provide a known 


hardware environment to simplify debugging. In addi- 
tion, the development hardware system can be adapted 
to changing application needs by adding Intel MULTI- 
BUS compatible 
boards to the iSBC 86/12A 
Single 


Board Computer. After the software is fully debugged, 
the application can be moved to the final custom hard- 
ware design. 


A spectrum analyzer is the subject of this application. 
The analyzer displays the frequency spectrum of an 
analog signal on a general purpose CRT terminal. The 
user has control over input signal bandwidth, averaging, 
and 
continuous 
analysis. 
A fast Fourier 
transform 


(FFT) program is used to obtain frequency data from 
samples of analog data. Fourier transforms provide use- 
ful frequency analysis, but the large processing require- 
ments of Fourier transforms have restricted their use. 
Fast Fourier transforms take advantage of the repetitive 
nature of the Fourier calculations, allowing the Fourier 
transforms 
to be completed significantly faster. The 


FFT used in this application note is known as "time de- 
composition with input bit reversal." 1 Sixteen-bit inte- 
ger samples of the input signal are placed in frames, 
with each frame holding 128 complex points. An aver- 
aged power spectrum is calculated to sum and square 
the FFT values, yielding 64 32-bit power spectrum 
values. These values are displayed on a standard CRT 
terminal. 


inter 


The FFf algorithm may be applied wherever frequency 
analysis of an analog signal is required. Medical appli- 
cations for FFfs 
include EEG analysis, blood flow 
analysis, and analysis of other low-frequency body sig- 
nals. Industrial uses are production 
line testing, wear 
analysis, frequency signature monitoring, 
analysis in 
noisy or hostile environments, 
and vibration analysis. 
Other applications 
could cover remote reduction 
of 
analog data, frequency correlation, and process control. 
For this application note, the actual use of the FFf 
is 


secondary to its existence as a modular, CPU-intensive 
task in a general purpose system. 


The overall application 
system characteristics are the 


following: 


1) A user-selectable input signal bandwidth of 120 Hz, 
600 Hz, 1200 Hz, 6000 Hz, or 12,000 Hz. 


2) The option 
of averaging frames of samples. The 
averaging is user selectable, with options of I (no 
averaging), 2, 4, 8, 16, or 32 frames averaged per 
CRT display. 


3 )The capability, also user selectable, of repeating the 
analysis cycle continuously. 


4) User capability to abort the analysis. 


5) Twelve-bit input sample resolution. 


6) A minimum of hardware requirements, including no 


more than 32K bytes of EPROM memory and 16K 
bytes of RAM memory. 


7) A standard character screen CRT for output. 


8) A multitasking 
structured 
design that 
will use a 


subset of the iRMX 86 Nucleus and exhibit modular 
application 
code, 
formal 
interfaces, 
and 
self- 


documentation. 


To begin the design, the application is broken up into 
functional modules, much the same as a hardware block 
diagram. A SUPERVISOR TASK initializes the system, 
accepts operator parameters, 
starts the analysis cycle, 


and stops the processing upon cycle completion 
or 


operator request. An INPUT TASK samples the data 
and places it in a buffer. An FFT TASK receives the 
buffer and processes the data. An OUTPUT TASK dis- 
plays the data received from the FFf TASK. This struc- 
ture is shown in Figure 6. 
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The general task functions are: 


SUPERVISOR TASK: The SUPERVISOR TASK ini- 
tializes the system by creating the other tasks. The 
SUPERVISOR TASK then obtains the analysis param- 
eters from the operator. Each parameter is verified as it 
is received. When all of the parameters are accepted, the 
operator is asked if they are satisfactory. If the operator 
agrees, the SUPERVISOR TASK sends frame buffers 
to the INPUT TASK to initialize the analysis. If not, the 
operator is asked to input all of the parameters again. 
During the FFf 
analysis, the SUPERVISOR 
TASK 


waits for an abort request from the operator and for the 
frame buffer from the OUTPUT TASK. If the abort re- 
quest is received, the SUPERVISOR TASK terminates 
the analysis in an orderly fashion and asks the operator 
for parameters for the next analysis cycle. If the frame 
buffer is received from the OUTPUT TASK and con- 
tinuous analysis has been selected, the SUPERVISOR 
TASK sends the frame buffer to the INPUT TASK to 
start the next cycle. If the frame buffer is received from 
the OUTPUT TASK and continuous analysis has not 
been selected, the current analysis is complete and the 
SUPERVISOR TASK asks for new parameters. 


INPUT TASK: The INPUT TASK receives the frame 
buffer from the SUPERVISOR TASK. The input signal 
is sampled according to the analysis parameters. 
The 


actual sample rates are calculated as follows: 


1) Multiply the highest frequency of interest by two to 


obtain the Nyquist sampling rate. 
2) Invert this value to obtain time between samples. 
3) Scale the value by 60/64. The CRT display is limited 


to 64 columns. The scaling maps sample values to 
columns 1 to 60 rather than 1 to 64, giving a more 
readable x-axis label and display. This method yields 
sample times of 3.9 milliseconds, 781 microseconds, 
390 microseconds, 78 microseconds, and 39 micro- 
seconds for frequencies of 120 Hz, 600 Hz, 1200 Hz, 
6000 Hz, and 12,000 Hz. 


The INPUT TASK samples the data at the required 
interval and places the samples in the frame buffer. 
When the frame buffer is full, the INPUT TASK up- 


dates the frame buffer number and sends the frame buf- 
fer to the FFT TASK. The INPUT TASK sends a status 
message to the CRT terminal and waits for the next 
frame buffer. 


FFT TASK: The FFf TASK receives the frame buffer 
from the INPUT TASK. A fast Fourier transform 
is 


performed 
on the data contained 
in the buffer, 
the 


power spectrum is calculated, and the data is averaged 
with previous data if necessary. If the frame buffer is 
the last one to be averaged prior to display of the fre- 
quency data, the frame buffer is filled with the averaged 
data and sent to the OUTPUT TASK. If the buffer is 
not the last one to be averaged, the FFf TASK returns 
the buffer to the INPUT TASK for another frame of 
data or to the SUPERVISOR TASK if the analysis cycle 
is nearly complete. The FFf TASK sends status infor- 
mation to the CRT display and waits for the next frame 
buffer from the INPUT TASK. 


OUTPUT TASK: The OUTPUT 
TASK receives the 


frame buffer from the FFf TASK. The data is format- 
ted and displayed. 
The OUTPUT 
TASK sends the 


frame buffer to the SUPERVISOR TASK and waits for 
the next frame buffer from the FFf TASK. 


Terminal Handler: The Terminal Handler serves as the 
basic I/O device for parameter 
requests, status data, 


and frequency displays. The Terminal Handler accepts 
display requests from all tasks and sends operator input 
to the SUPERVISOR TASK. 


The basic functions of the various tasks in the applica- 
tion have been defined, but system integration has not 
been discussed. Synchronization of the tasks, schedul- 
ing, resource management, mapping to hardware, inter- 
rupt handling, and system interfaces have been omitted. 
No debugging functions have been defined. It is clear 
the system implementation is just started. The iRMX 86 
Nucleus will provide 
all of the system integration 
"glue" 
the application 
requires, allowing application 


programmers 
to concentrate on the actual functional 


code. In order to use this "glue," 
the application must 


be divided into jobs and tasks. 


The iRMX 86 Operating 
System architecture 
defines 


jobs as separate environments within which tasks oper- 
ate. These separate environments 
allow each job to 


function with no knowledge of other system jobs. There 
are two jobs in this application, the Debugger job and 
the Application job. 


The jobs contain functional portions or working pro- 
grams called tasks. The Application job contains the 
INIT TASK, SUPERVISOR 
TASK, INPUT 
TASK, 


FFf 
TASK, 
OUTPUT 
TASK, 
and 
INTERRUPT 


TASK. The Debugger job contains the Debugger task 
and the Terminal Handler task. Tasks provide the ap- 
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plication -goalsof modularity, resource constraint boun- 
daries, and functional independence. The structure of 
the development system is shown in Figure 7. 


Figure 
7. Development 
System 
Job Structure 


The Debugger job is included only for development. 
When development is completed, the Debugger job is 
removed from the system. A Terminal Handler job con- 
taining only the Terminal Handler task is substituted in 
place of the Debugger job. The application code is not 
changed. This structure is shown in Figure 8. 


Figure 
8. Final System 
Job Structure 


Interfaces and Synchronization 


Now that the system is made of jobs and tasks, the 
primary need is to synchronize the tasks and provide 
communication interfaces. This will be handled by mail- 
boxes. The messages sent via the mailboxes will be seg- 
ments, which are pieces of memory allocated by the 
Nucleus. The frame buffers sent from task to task are 
these segments. The buffer segments contain all the 
analysis parameters 
in addition to the data samples. 


Communication 
with the Terminal Handler task is also 


accomplished by mailboxes, but with a different buffer 
format. The Terminal Handler format has fields for the 
operation 
requested 
(read or write), the number 
of 


characters the task wishes to read or write, the number 


of characters the Terminal Handler did read or write, a 
status field for the operation, and the actual data. The 
buffer format is shown in Figure 9. Figure 12 contains 
the Terminal Handler segment format. 
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Figure 9. 
Frame 
Buffer 
Format 


Mailboxes are used to pass the buffer segment from task 
to task. Tasks can send segments to mailboxes, 
or 


receive segments from mailboxes. If there is no segment 
at a mailbox, a task can elect to wait for the segment, 
with the wait duration 
ranging from zero to forever. 


This provides the simplest system synchronization 
- 


each task, upon initialization, waits at its input mailbox 
for a frame buffer segment. When the task receives the 
segment, it processes the data, sends the segment on to 
the mailbox for the next task, and returns to its own 
mailbox to wait for the next frame buffer. The system is 
synchronized and controlled by the availability of frame 
buffers and task priority. It should be clear that multi- 
ple frame buffers segments provide overlapped process- 
ing, with the segments ultimately "piling up" 
at the 


slowest task in the chain. This loose coupling arrange- 
ment allows tasks to have radically different execution 
times. For example, the INPUT TASK has an input 
sampling time that ranges from 0.6 seconds to 6.3 milli- 
seconds, a range of 100to I, and the system requires no 
special synchronization or scheduling to accommodate 
this range. 


The mailbox 
interfaces, 
shown in Figure 
10, serve 


several other important 
purposes. First, they provide 


the standardized interface that is a goal of this applica- 
tion. The set of mailboxes and the two buffer segments 
form all inter-task interfaces. Each task uses only a few 
mailboxes, making it easy to add or remove tasks by 
adding or removing mailboxes. The system could easily 
be expanded to include data reduction tasks, data cor- 
relation tasks, or to substitute different tasks for any of 
the present ones. Dummy tasks were used for real tasks 
during development to verify overall system execution 
before the actual tasks were available. 


inter 


Figure 10. Application Architecture with 
Mailboxes. 


The mailboxes also provide a very convenient window 
into the application system processing for both debugg- 
ing and aborting the current cycle. The Debugger can set 
breakpoints at mailboxes to allow users to examine the 
frame buffers as they progress from task to task. The 
Debugger can examine buffer data and control the pro- 
cessing cycle. Tasks wait at the mailboxes in a queue 
that is either priority or first-in-first-out (FIFO) based. 
The inter-task mailbox queues are priority based, which 
means the higher priority SUPERVISOR TASK can in- 
tercept segments at the mailboxes ahead of the lower 
priority waiting tasks, and abort the analysis by remov- 
ing all of the buffer segments. This method of aborting 
requires no knowledge of the internal processing of the 
tasks, making it universally applicable to all the tasks. 


A return mailbox may be specified when a segment is 
sent to a mailbox. The receiving task may send status in- 
formation, a different segment, or the original segment 
to the return mailbox. The Terminal Handler will return 


the buffer segment sent to it if a return mailbox is 
specified. This is used to synchronize the tasks with the 
Terminal Handler and to allow multiple tasks to use a 
single display task. Each sending task waits at a separate 
return mailbox for the Terminal Handler to return its 
segment. Each task retains control over its buffer seg- 
ment and is synchronized with the slower data display 
function. 


In addition to the mailboxes, task execution is governed 
by priority. In this system, the INPUT TASK has maxi- 
mum priority to guarantee it can sample the input signal 
at the precise intervals 
required 
for the FFT. 
The 


SUPERVISOR TASK, responsible for abort functions, 
has the next level of priority, with the FFT TASK next, 
and the OUTPUT TASK lowest. 


Display Functions 


All application tasks use the iRMX 86 Terminal Han- 
dler as an output 
device. The Terminal 
Handler 
is 


chosen because it provides a standard interface consis- 
tent with the application goals, it exists both in the De- 
bugger job and in an independent job, and it is easy to 
integrate into the application system. The application 
could also use the same interface with a user-written 
Terminal 
Handler. 
In this application, 
the Terminal 
Handler can have messages from four tasks on the 
screen at one time. To allow this to occur in an orderly 
fashion, lines on the screens are reserved for each of the 
tasks. The screen format is shown in Figure II. Each 
message to the screen sends the cursor to the upper left 
corner (the horne position), then down to the proper line 
to display the data. 


, 
I, 
," 
, U,h , 
" 
IIiI, I, 
, 
'''UUII'''''' 
, 
, u"uu",,,,,,,,, 
, 


• ~ 
+. 
h 
~!!~! 
!!!!!!!f!!!! !!!!!t!!~! ._ 
t __ 


o 
1000 
2000 
3000 
4000 
5000 
6000 


Current 
settings 
are 
the 
following: 
frequency 
range 
0 to 
6000 
Hz. 
} 
SUPERVISOR 


16 
frall1es 
to 
average 
per 
output 
display. 
and 
continuous 
runs. 
TASK 


The 
INPUT TASK has 
processed 
16 frames 
out 
of 
16 frames 
to 
average. 
_ 
INPUT 
TASK 


The 
FFT TASK has 
processed 
16 
frames 
out 
of 
16 
frar:>es 
to 
average. 
- 
FFT 
TASK 


Cataloging 


To aid the debugging process, all system objects, such as 
mailboxes, segments, and tasks, are cataloged in the 
directory of the SUPERVISOR TASK. The catalog en- 
tries are user-selected, l2-character names. The Debug- 
ger can display this directory, giving easy access to ob- 
jects to aid symbolic debugging. If other tasks know the 
proper directory and the I2-character name, the tasks 
can look up the objects in the directory and obtain ac- 
cess to them. This is the method used to find the Ter- 
minal Handler mailboxes. For objects that are cataloged 
only to aid debugging, the system calls that catalog the 
objects are removed from the code when debugging is 
complete. 


Application Code 


The code listings for the SUPERVISOR TASK and the 
INPUT TASK are included in appendices to this note. 
Code listings for other tasks are not included, but they 
are available from the Intel Insite software library. The 
following discussions reference line numbers in the list- 
ings included in this note. The references begin with a 
first letter for the appendix section (A or 8), followed 
by the actual line number (A.220, for example). 


Code listings for the SUPERVISOR TASK are in Ap- 
pendix A. The actual SUPERVISOR TASK procedure 
begins at line A.550. After initializing internal buffers 
and mailboxes (A.551, A.518-A.549), 
the Supervisor 


sends an initial screen, one line at a time, to the Termi- 
nal Handler (A.553, A.502-A.517). When the screen is 
complete, the SUPERVISOR TASK creates the INPUT 
TASK, 
FFf 
TASK, 
and 
OUTPUT 
TASK (A.554, 
A.486-A501). 
The order of creation is not important 


for this application, as each task begins by waiting at its 
input mailbox for frame buffer segments. The SUPER- 
VISOR TASK requests input parameters from the oper- 
ator (A.556, A.305-A.485). The actual input parameter 
loop is found at A.478. The loop consists of asking 
questions (A.479, A.480) until all answers are satisfac- 
tory. The operator is asked to choose the highest fre- 
quency of interest, number of frames to average, and 
single runs or continuous 
runs (A.331-A.353). 
If the 


operator answers with an invalid input, the question is 
repeated (A.365 and A.415). If the operator wishes to 
abort the questioning by entering a 99, the questions' 
start over from the first question (A.409-A.413). When 
all three questions have been answered, the operator is 
asked to confirm his choice (A.482, A.418-A.467). 
If 
the operator does not verify the answers, the question 
number is set to 0 (A.463) and the parameters are re- 
quested again. If he confirms the answers as correct, the 
SUPERVISOR TASK creates up to three frame buffer 
segments (A.557, A.279-A.304). 
The SUPERVISOR 


TASK places the binary equivalents of the operator 
answers in the frame segments (A.284, A.292, A.300, 
A.269-A.278), 
and sends the segments to the input 


mailbox for the INPUT TASK (A.287, A.294, A.302). 


The SUPERVISOR TASK's background duties are to 
check its input mailbox for a segment from the OUT- 
PUT TASK and to check a return mailbox for an abort 
request from the operator 
(A.558, A.225-A.268). 
If 


segments are received at the SUPERVISOR TASK mail- 
box, the SUPERVISOR TASK sends the segments on to 
the INPUT TASK if the operator has chosen continuous 
runs (A.258). Otherwise, the SUPERVISOR TASK de- 
letes 
the 
segments 
(A.242-A.250). 
When 
all 
the 


segments 
have been deleted, 
which halts 
the 
FFf 


analysis, the SUPERVISOR TASK asks for operator in- 
put again (A.556). 


If an operator abort request is received, the SUPER- 
VISOR TASK, having higher priority than the FFf or 
OUTPUT TASKS, waits at their mailboxes to intercept 
the 
frame 
segments 
(A.243, 
A.249, 
A.207-A.224). 


When a segment is received it is deleted (A.219). The 
SUPERVISOR 
TASK also checks the INPUT TASK 


mailbox under abort conditions (A.244). This mailbox 
is FIFO based to allow the SUPERVISOR TASK to in- 
tercept the buffer segment ahead of the higher-priority 
INPUT TASK (A.523). The SUPERVISOR TASK in- 
put mailbox is also checked for frame buffer segments 
that may have been sent there by the OUTPUT TASK 
after the abort was requested (A.246). When all of the 
frame buffer segments have been deleted, the SUPER- 
VISOR TASK asks for operator input (A.556). 


Listings of the INPUT TASK are in Appendix 8. After 
initializing the buffer for Terminal Handler communi- 
cations and the mailboxes for communicating with the 
INTERRUPT TASK and the Terminal Handler (8.335, 
8.302-8.333), 
the INPUT TASK waits at its input mail- 


box for a frame buffer segment (8.338). 


When a frame segment is received, the INPUT TASK 
updates the frame number counter kept by the INPUT 
TASK (8.340,8.289-8.301), 
and samples the analog in- 


put (8.341, 8.231-8.288). 
The INPUT TASK selects 


one of two input driver routines, either a software poll- 
ing loop for faster sampling rates (8.277-8.281), 
or an 


INTERRUPT 
TASK 
for 
slower 
sampling 
rates 


(8.251-8.276). 
If the sampling is driven by interrupts 


and a Nucleus system call is executing at the time of the 
interrupt, the time required to respond to that interrupt 
can vary from 100 to 350 microseconds, depending on 
the Nucleus call in progress. For the sample rates of 391, 
78, and 39 microseconds, corresponding to bandwidths 
of 1200, 6000, and 12,000 Hz, the system interrupt 
latency cannot guarantee the precise sampling interval 


required. A a simple software polling loop with a delay 
between samples is used for these rates (assembler code 
for this loop is included after the INPUT TASK listings 
in Appendix B). This loop operates at priority 0, the 
highest priority, to guarantee the loop is not interrupted 
(B.278, B.280) while the sampling is in progress. 


For the longer intervals of 3.9 milliseconds and 781 
microseconds, corresponding to bandwidths of 120 and 
600 Hz, an Interrupt 
Handler and and INTERRUPT 


TASK are used (B.251-B.276). 
Under the iRMX 86 


Operating System architecture, an Interrupt Handler is 
defined as a short procedure with a primary goal of fast 
interrupt response and limited Nucleus calls. All hard- 
ware interrupt 
levels are masked when an Interrupt 


Handler is responding to an interrupt. 
If the interrupt 


servicing requires higher-level system functions, the In- 
terrupt Handler notifies a waiting INTERRUPT TASK. 
Higher-level interrupts 
are enabled when an INTER- 


RUPT TASK is executing. INTERRUPT 
TASKS can 


make all system calls. 


The INTERRUPT 
TASK (B.I96-B.203) 
binds the In- 


terrupt Handler to the hardware interrupt level (B.I97) 
and waits for a signal from the Interrupt 
Handler 


(B.I99). The Interrupt Handler (B.I64-B.I95) 
verifies 


the interval accuracy (B.I66-B.I73), 
samples the data 


(which automatically 
starts the next sample) (B.I75- 


B.I76), places the data in the frame buffer (B.18I- 
B.I84), and notifies the INTERRUPT TASK when the 
frame buffer is full (B.I93). If the buffer is not full, the 
Interrupt Handler resets the interrupt hardware (B.I94). 
The INTERRUPT 
TASK notifies the INPUT TASK 


(B.200) and waits for a return message (B.201). The IN- 
PUT TASK disables interrupt 
level 3 (B.274) and re- 
turns the token to the INTERRUPT TASK (B.275). The 
INTERRUPT 
TASK enables the Interrupt 
Handler 


(B.I99), but no interrupts will be received from the free- 
running 8253 Timer because hardware interrupt level 3 
has been disabled. Sampling for the next buffer is in- 
itiated by simply enabling level 3 (B.272). The INPUT 
TASK sends a status message to the Terminal Handler 
(B.342, B.219-B.230) and sends the filled frame buffer 
to the FFT TASK (B.343). The INPUT TASK then 
returns to the INPUT TASK input mailbox to wait for 
the next frame segment (B.338). 


Listings for the FFT TASK are not included with this 
application note. The FFT TASK is similar in overall 
format to the INPUT TASK. The FFT TASK waits at 
its input mailbox for a frame buffer segment from the 
INPUT TASK. When one is received, the FFT TASK 
computes the fast Fourier transform of the data. The 
auto power spectrum is computed and averaged with 
previous data. The FFT TASK sends its status message 
to the Terminal Handler for display. If the frame buffer 


is the final one to be averaged, the FFT TASK sends the 
frame buffer to the OUTPUT TASK. If the frame buf- 
fer is not the final one in this averaging series, the FFT 
TASK checks to see if the sampling process is continu-, 
ous. If so, the frame buffer is returned to the INPUT 
TASK. If the sampling process is not continuous and 
the buffer is within two frames of the final frame buf- 
fer, the buffer is returned to the SUPERVISOR TASK 
to prevent unnecessary buffers from going to the IN- 
PUT TASK. The FFT TASK then returns to its input 
mailbox to wait for the next frame buffer. 


Listings for the OUTPUT TASK are not included in this 
application note. The OUTPUT TASK, like the other 
tasks, waits at its input mailbox for a buffer. When a 
frame buffer is received from the FFT TASK, the OUT- 
PUT TASK stores the data in an internal buffer and 
sends the frame buffer to the SUPERVISOR TASK. 


The OUTPUT TASK converts each 32-bit frame buffer 
value to one of 16 levels by taking the base 2 logarithm 
of the significant 16 bits of sample value. The display 
screen is sent to the Terminal Handler one line at a time. 
Each line of the display is composed of 7 characters of 
label and y-axis data and 64 characters of display data 
(reference Figure 11). Each line of the display represents 
a power of two (from 16down to 1). The character to be 
displayed at each location is found by comparing the ap- 
propriate sample value against the current line value. If 
the sample value is greater than the line number, 
a 


pound sign is displayed at that location. Otherwise, a 
space is displayed. The x-axis and labels are sent after 
the data lines to complete the display. The OUTPUT 
TASK then waits at its input mailbox for another frame 
buffer. 


The Terminal 
Handler 
interfaces 
to the application 


tasks via the two mailboxes and buffer segment format 
shown in Figure 12. If a task wishes to display data, a 
segment containing the data is sent to the RQ$TH$- 
NORM$OUT 
mailbox, 
specifying a return 
mailbox. 


The Terminal Handler displays the data, updates the 
status 
fields, and 
sends the segment to the return 


mailbox. 


Input 
proceeds 
in much the same fashion. 
A task 


requesting 
data 
sends 
a 
segment 
to 
the 


RQ$TH$NORM$IN mailbox, again specifying a return 
mailbox. When the operator terminates the input line 
with a carriage return, the Terminal Handler puts the 
data in the segment, updates the status fields, and sends 
the segment to the return mailbox. 
This serves two 


primary purposes: specifying return mailboxes allows 
multiple tasks to share the display screen while retaining 
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synchronization and control over their data buffers; and 
a user-written Terminal Handler using the same pro- 
tocol and mailbox names could easily be integrated into 
the application. For this application, the INPUT TASK, 
FFT 
TASK, 
OUTPUT 
TASK, 
and 
SUPERVISOR 


TASK all share the screen for output, 
but only the 


SUPERVISOR TASK uses the Terminal Handler to ob- 
tain operator input. 


The iRMX 86 Nucleus provides a comprehensive set of 
61 system calls. A complete description of these calls 
may be found 
in the iRMX 86 Nucleus Reference 


Manual. For most applications, only a subset of the 61 
calls will be required. The iRMX 86 Nucleus is configur- 
able, which means the final system Nucleus will contain 
code only for the system calls required for the applica- 
tion. 
In this case, the following system calls were 


required: 


RQ$CREA TE$MAILBOX, 
RQ$SEND$MESSAGE, 
and RQ$RECEIVE$MESSAGE 
provide mailbox man- 


agement. 


RQ$CREA TE$SEGMENT 
and 
RQ$DELETE$SEG- 


MENT are used to create and delete segments for the 
frame buffers, internal buffers, and Terminal Handler. 


RQ$SET$INTERRUPT, 
RQ$EXIT$INTERRUPT, 


RQ$SIGNAL$INTERRUPT, 
RQ$WAIT$INTER- 


RUPT, 
RQ$ENABLE, 
and RQ$DISABLE allow the 


INPUT TASK to handle hardware interrupts knowing 
only the hardware interrupt level (3). 


RQ$CREA TE$JOB, 
RQ$CREATE$TASK, 
and 


RQ$SET$PRIORITY 
are used to create the jobs and 


tasks, and set the priority of the input polling loop. 


RQ$GET$T ASK$TOKENS, RQ$LOOKUP$OBJECT, 
RQ$CA TALOG$OBJECT, 
RQ$DISABLE$DELE- 


TION, RQ$ENABLE$DELETION, 
RQ$GET$TYPE, 


RQ$GET$PRIORITY, 
RQ$GET$SIZE, 
and RQ$SIG- 


NAL$EXCEPTION 
are system calls required by the 


Debugger and the Terminal Handler. 
None of these 


calls are necessary in this application if a user-written 
Terminal Handler is used and debugging is completed. 


System Configuration 
is the integration 
step in the 


development process. It consists of selecting the por- 
tions of the iRMX 86 Operating System required in the 
application, mapping this code and the application code 
to system memory, and creating a Root Job that will in- 
itialize the system. The overall configuration process is 
shown in Figure 13. Configuration 
requires knowledge 


of available memory, operating system and application 
code entry points, priorities, exception handlers, and 
other system parameters. System Configuration consists 
of the following steps: 


I) Selecting the portions 
of the iRMX 86 Operating 


System required by the application, 
including the 


layers and the specific system calls in each layer. 


2) Linking and locating those portions. 


3) Assembling or compiling, linking, and locating the 


application code. 


4) Creating a configuration file that will tell the Nucleus 


the locations of available RAM memory, initial char- 
acteristics of each system job, and pertinent overall 
system parameters. Each job in the system has an en- 
try in the configuration file. The order of the entries 
is the order of initialization of the jobs. 


5) Creating the Root Job by assembling, linking, and 


locating the configuration file. 


LINKED 
& 
LOCATED 
iRMX 86 
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LINKED 
& 
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APPLICATION 
CODE 


During development of an EPROM-based 
application 


such as this one, configuration 
is accomplished twice: 
once for the RAM-based development system and once 
for the final EPROM-based 
system. These configura- 
tions are detailed in Appendix C, System Configura- 
tion. In both cases, the Root Job that results from con- 
figuration initializes the system jobs. For development, 
the system job structure is shown in Figure 7. The Root 
Job creates the Debugger Task in the Debugger Job, 
which in turn creates the Terminal Handler Task. The 
Root Job then creates the SUPERVISOR TASK, which 
creates the INPUT TASK, FFf TASK, and OUTPUT 
TASK. The INPUT TASK creates the INTERRUPT 
TASK when necessary. 


Software development is completed on the iSBC 86/12A 
Single Board Computer discussed earlier in this note. 
After application 
code is debugged and ready to be 
placed in EPROM memory, the Debugger Job, which 
contains both the Debugger and the Terminal Handler, 
is removed and replaced with the Terminal Handler 
Job, which contains only the Terminal Handler. This 
job structure is shown in Figure 8. The Nucleus system 
calls required only by the Debugger are removed from 
the iRMX 86 Nucleus. The application 
code is not 
changed. 
The 
application 
code and 
the iRMX 
86 
Nucleus is configured 
for the final system, put in 
EPROM memory, and tested on the final hardware sys- 
tem. The final Nucleus and application code required 
30.5K bytes of EPROM, allowing room for futllre code 
changes and some expansion within the 32K system 
limit. 


The final application hardware is shown in Figure 14. 
This system contains an iAPX 86/10 CPU, an 8259A 
Programmable 
Interrupt Controller, and an 8253 Pro- 


grammable Timer. The three chips form the primary 
hardware requirements for the iRMX 86 Operating Sys- 
tem. The system is assembled from Intel components, 
using standard support circuits and system schematics 
described in Intel documentation. 
The analog sampling 
circuitry is a 12-bit analog to digital converter (ADC) 
and a sample/hold circuit. Both the sample/hold circuit 
and the ADC are driven from ·the on-board local bus. 
The ADC has a conversion time of 35 microseconds, 
limiting the overall cycle to approximately 
39 micro- 
seconds per sample, or a maximum CRT display band- 
width of 12,000 hz. 


The hardware system shown in Figure 14 contains com- 
ponents not specifically required for the final configura- 
tion. The 8255A Programmable 
Peripheral 
Interface 
and the MULTIBUS multimaster interface are not nec- 
essary for a system limited to just spectrum analysis and 
display via the CRT. However, the flexibility advan- 
tages of the iRMX 86 Operating System are supported 
by this hardware. For instance, the frequency spectrum 
display is limited by the CRT to a 16-levellogarithmic 
approximation. 
Accuracy could be improved by using 


the programmable peripheral interface to drive a plotter 
or an analog CRT via a digital to analog converter. 
Software drivers for the plotter or CRT could be new 
tasks, interfacing to the old tasks through the mail- 
boxes. Or, the OUTPUT 
TASK could be simply re- 
placed with a new OUTPUT TASK for the plotter and 
analog CRT. The inclusion of the MULTIBUS interface 
allows this application 
to be integrated into a larger 
system of MULTIBUS-compatible 
boards. 
MULTI- 


BUS-compatible memory boards will also aid test and 
debug. Users of hardware components can include these 
modular Intel interfaces as required by their applica- 
tion, giving growth and configurability 
in both hard- 


ware and software. 


Figure 14. 
Final Hardware 
System 
Block Diagram 


PL/M 
86™ Compiler, 
MCS-86™ Macro Assembler, 


and the MCS-86 Utilities LINK86, LOC86, and OH86. 
The Intel UPP-1O3™ Universal PROM Programmer is 
used to convert the final system to PROM memory. 
This broad support allows expedient development of 
prototype 
and final systems based on the iRMX 86 


Operating System. 


This application note discussed general operating sys- 
tem functions, the Intel iRMX 86 Operating System, 
using the iRMX 86 Operating System on hardware com- 
ponent systems, and an example of an application im- 
plemented in a component environment. 
Users of the 


iRMX 86 Operating System are able to simplify applica- 
tion code development through modularity, 
standard 
interfaces, 
freedom from rigid hardware 
restrictions, 


and advanced 
debugging techniques. 
The iRMX 86 
Operating System can be applied to larger systems by 
adding other iRMX 86 layers, making the software in- 
vestment 
beneficial over a wide range of applications. 


Operating systems provide many advantages for hard- 
ware component designs, but all of these benefits can be 
utilized only if the operating system and the develop- 
ment environment are fully supported. 
Intel's support 
for this application begins with an Intel MDS 230 Series 
II Microcomputer Development System. The MDS 230 
System 
interfaces 
with 
the 
development 
hardware 


through the iSBC 957A™ Monitor. The development 
hardware is an Intel iSBC 86/l2A 
Single Board Com- 
puter, an Intel iSBC 7II ™ Analog Input Board, an Intel 
iSBC 032™ 32K RAM Memory Board, an Intel iSBC 
064TM64K RAM Memory Board, and an Intel iSBC 
660™ System Chassis. Final application hardware is de- 
bugged using Intel's 
ICE-86™ 8086 In-Circuit Emu- 
lator. 
Software 
support 
is provided 
by the ISIS-II 


The iRMX 86 Operating Systems and the Intel develop- 
ment tools are valuable only if they translate directly to 
increased productivity and shortened time to market for 
new products. This application has 1567 lines of appli- 
cation code. It was developed, from design to final im- 
plementation, in approximately 9 man-weeks of effort. 
This high level of productivity was achieved with the 
added benefits of modularity, standardization, 
and ease 


of application growth. 


Intel Corporation 
is committed to both the continued 


integration of higher-level functions into hardware and 
to maintaining compatibility of present software with 
new hardware. One result of these commitments will be 
the Intel iAPX 86 and iAPX 286 Processors, which will 
be compatible with the iRMX 86 Operating 
System. 


Another result will be the placement of the iRMX 86 
Operating 
System Nucleus into hardware. 
This will 


allow custom hardware applications to have higher-level 
functions, simplified development, and decreased chip 
count. Using the iRMX 86 Operating System today will 
give hardware component users a headstart on Intel's 
technological innovation for tomorrow. 


inter 


APPEN DIX A 
2-262 
APPEN DIX B 
2-283 


APPEN DIX C 
2-300 


PL/M-86 
COMPILER 
SUPERVISOR 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980 
ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
SUPERVISOR 
MODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:superv.OBJ 


COMPILER 
INVOKED 
BY: 
plm8~ 
:Fl:superv.p8~ 


Stitle(' 
SUPERVISOR 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980') 
Slarge 
<'lebug 
SUPERVISOR 
MODULE: 


do; 
Sinclude(:fl:nuclus.ext) 
SSAVE 
NOLIST 


/************************************************/ 
/* The 
six 
mailboxes 
immediately 
following 
will 
*/ 
/* form 
all 
of 
the 
inter-task 
communications 
*/ 
/* 
interfaces 
for 
the 
five 
tasks 
that 
run 
in 
*/ 
/* this 
system. 
*/ 
/************************************************/ 


090 
1 
declare 
th 
in mbx 
token; 


091 
1 
declare 
th-out 
mbx 
token; 


092 
I 
declare 
to- input 
mbx 
token 
public; 
093 
1 
declare 
to-fft 
mbx 
token 
public; 
094 
1 
declare 
to-output 
mbx 
token 
public; 
095 
1 
declare 
to-supervIsor 
mbx 
token 
public; 


09') 
1 
declare 
return 
th 
in mbx 
token; 
097 
1 
declare 
return -th-out 
mbx 
token; 


098 
1 
declare 
dumrny_mbx 
token; 


099 
1 
declare 
frame 
segment 
one 
token; 
100 
1 
declare 
frame -segment -two 
token; 


101 
1 
declare 
frame -segment -three 
token; 


102 
1 
declare 
th 
in-segment -token 
token; 


103 
1 
declare 
th-out 
segment 
token 
token; 
- 


104 
1 
declare 
general 
index 
hyte; 
105 
1 
declare 
number 
of 
fft 
data 
segments 
byte; 
- 


106 
1 
declare 
insert 
text 
pointer 
pointer; 
- 


107 
1 
declare 
abort 
flqg 
\~ord; 


108 
1 
declare 
status 
word; 


109 
1 
declare 
segment 
deleted 
tally 
word; 


110 
1 
declare 
text 
length 
word; 
- 


III 
1 
declare 
root 
job 
token 
token; 
112 
1 
declare 
input 
task 
token 
token; 


113 
1 
declare 
fft 
task 
token 
token; 


114 
1 
declare 
output 
task 
token 
token; 


115 
1 
c1eclare 
parameters 
structure( 


actual 
samples 
word, 
- 


inter 


116 
117 
118 
119 
120 
121 
122 
123 
124 
12S 
126 
127 
128 
129 
130 
131 
132 
133 
134 


136 
137 


139 
140 


declare 
declare 
declare 
declare 
declare 
decliHe 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 


actual 
interval 
frequency 
answer(S) 
actual 
frames 
to 
average 
frames-to 
average 
answer(S) 
continuous 
flag 
- 
continuous=flag_answer(S) 


abort 
ascii 
9 
carriage 
return 
forever 
- 
line 
feed 
new 
tft 
run 
no abort 
no 
response 
requested 
null 
- 
queue_fifo 
queue 
priority 
root job 
run 
conti.nuous 
size 
120_bytes 
space 
supervisor 
job 
th 
read 
- 
th-write 
waTt 
forever 


word, 
byte, 
word , 
byte, 
word, 
byte) ; 


literally 
'OFFH'; 


literally'039H'; 
literally'ODH'; 
literally 
'while 
1'; 


1 iterally 
'OAH'; 


literally 
'OFFH'; 


li terally 
'OOH'; 
literally'OOH'; 
literally 
'OOH'; 


literally 
'OOH'; 


literally'OlH'; 
literally'03H'; 
literally 
'OFFFFH'; 


literally 
'120'; 


literally'20H'; 
literally 
'OOH'; 


literally'OlH'; 
literally'OSH'; 
literally'OFFFFH'; 


/* 
The 
following 
declaration 
sets 
the 
characters 
*/ 


/* 
to 
send 
the 
cursor 
home 
at 
the 
beginning 
of 
*/ 


/* 
each 
message 
to 
the 
display 
screen. 
The 
*/ 


/* 
seqeunce 
is 
tilde, 
DC2 
(Hazeltine»). 
*/ 


declare 
declare 
frame 
pointer 
fram~-pointer 
values 
offset 
wo rd, 
base 
word) 
at 
(@frame_pointer); 


pointer; 
structure( 


declare 
frame 
based 
frame 
pointer 
samples 
per 
frame- 


sample 
interval 
frames-to 
average 


continuous 
flag 
this 
frame-number 
number 
samples 
missed 
sample-po 
inter- 


reset 
flag 
sample 
(2S6) 


declare 
declare 


structure( 
wo rd, 
wo rd, 


"/0 rd , 
word, 
word, 
word, 
word, 
word, 
integer) 
; 


th 
in 
segment 
pointer 
th-in-segment-pointer 
values 
offset 
word, 
- 
base 
word) 
at 
(@th_in_segment_pointer); 


pointer; 
structure( 


inter 


142 
143 


th 
in 
segment 
structure 
( 
function 
count 
exception 
code 
actual 
- 
message(112) 


word, 
word, 
word, 
word, 
byte) ; 


geclare 
th 
out 
segment 
pointer 
pointer; 
declare 
th-out 
segment-pointer 
values 
structure( 
offset-word, 
- 
base 
word) 
at 
(@th_out_segment_pointer); 


declare 
th 
out 
segment 
structure 
( 
function 
count 
exception 
code 
actual 
home 
chars(2) 
line-index(24) 
message(84) 


word, 
word, 
word, 
word, 
byte, 
byte, 
byte) ; 


declare 
frequency 
question(*) 
byte 
data 
('Please' 


, enter 
the 
highest 
frequency 
in 
Hz 
(120, 


, 
?; 00, 
1200, 
11000, 
OR 
l/.000) : ') ; 


declare 
frequency 
answers 
data(*) 
byte 
data 
(05H, 
03H,03H,04H,04H,05H,OH, 
, 
120 
nOO 
1200 
1100012000 
42H,OFH, 
00DH,03H, 
OR7H,01H, 
4EH,OOH, 
027H,OOH, 
OOH,OOOH); 


declare 
average 
question(*) 
byte 
data 
{'Please' 
, enter-the 
number 
of 
frames 
to 
average' 
(1, 
2, 
4, 
8, 
16, 
OR 
32): '); 


declare 
average 
answers 
data(*) 
byte 
data 
(OI1H, 
01H,01H~01H,01H~02H,02H, 
, 
1 
2 
4 
8 
Hi 
32' , 
OlH,OOH, 
02H,00H, 
04H,00H, 
08H,OOH, 
10H,00H, 
20H,rOH); 


declare 
continuous 
question(*) 
byte 
data 
('Please' 


, enter' 
'1" 
for 
one 
sample 
run 
or 
"C' 
I' 


, for 
continuous 
running: 
'); 


declare 
continuous 
answers 
data(*) 
byte 
data 
(03H, 


OlH,OlH,OlH,OOH,OOH,OOH, 
, 
1 
C 
c 
OOH,OOH, 
OFFH,OFFH, 
OFFH,OFFH, 
OOH,oOH, 
OOH,OOH, 
oOH,OOH); 


declare 
reject 
message(*) 
byte 
data 
('I cannot' 


, accept 
your 
answer. 
PLEASE 
TRY 
AGAIN.'); 


decla~e 
status 
line one(*) byte data 
('Cu~~ent' 
, settTngs 
a~e the following: 
f~equency' 
, ~ange 
0 to 
HZ,'); 


decla~e 
status line two(*) byte data 
(' 
, f~ames to-ave~age 
pe~ output display,' 
, and 
'); 


decla~e 
continuous 
~uns(*) byte data 
('continuo~s 
~uns.'): 


decla~e 
single 
~un(*) byte data 
('a single 
~un. 
'): 


decla~e 
go ahead question(*) 
byte data 
('If' 
'these settings 
a~e co~~ect, 
ente~ 
"G" 
'to begin 
~unning.'); 


decla~e 
heade~ 
line one(*) byte data 
(' INTEL' 
, APNOTE 
110--THE iRMX 86 OPERATING 
SYSTEM' 
, AND iAPX 86 COMPONENT 
DESIGNS.'): 


/************************************************/ 
/* The following 
th~ee p~ocedu~e 
decla~ations 
*/ 


/* link the tasks outside 
the SUPERVISOR 
MODULE 
*/ 
/* with 
the supe~viso~ 
task. 
*/ 
/************************************************/ 


158 
1 
INPUT TASK: 
PROCEDURE 
EXTERNAL; 


159 
? 
END INPUT_TASK; 


150 
1 
FFT TASK: 
PROCEDURE 
EXTERNAL; 


161 
2 
END-FFT_TASK: 


152 
1 
OUTPUT TASK: 
PROCEDURE 
EXTERNAL: 


163 
2 
END OUTPUT_TASK; 


/***********************************************/ 
/***********************************************/ 
/** The following 
five p~ocedu~es 
a~e gene~al 
**/ 
/** utility p~ocedu~es 
called by the p~ima~y 
**/ 
/** wo~king 
p~ocedu~es. 
**/ 
/***********************************************/ 
/***********************************************/ 


/********************************************/ 
/* Blank line just fills the message 
buffe~ 
*/ 
/* with blank 
cha~acte~s. 
*/ 
/********************************************/ 


161i 
1157 


175 
1 


176 
2 
177 
2 
178 
2 


179 
2 


180 
2 
181 
3 


182 
3 


1R3 
2 
184 
3 


185 
3 
186 
3 


187 
2 


188 
2 


do 
blank 
line 
index 
= 
0 to 
78; 
th_out_segment.message 
(blank_line_index) 


= 
space; 


th 
out_segment.message 
(79) 


END 
BLANK_LINE; 


/*****************************************/ 
/* 
DISPLAY 
LINE 
sends 
the 
message 
to 
the 
*/ 
/* terminal 
handler 
output 
mailbox 
and 
*/ 
/* waits 
for 
the 
segment 
to 
be 
returned. 
*/ 
/*****************************************/ 


call 
rq$send$message 
(th out 
mbx, 
th-out-segment 
token, 
return-th 
out 
mbx, 
~status); 
th_out_segment 
token 
rqSreceive~message 
(return 
th 
out 
mbx, 


wait 
forever,-~dummy 
mbx, 


@status;) 
- 


/************************************************/ 
/* 
INSERT 
TEXT 
fills 
the 
output 
message 
segment 
*/ 
/* with 
the 
chosen 
message 
and 
pads 
the 
rest 
of 
*/ 
/* 
the 
line 
with 
blanks. 
*/ 
/**********************************************~*/ 


declare 
declare 
declare 


text 
pointer 
pointer; 
how 
many 
word; 
dummy 
based 
text 
pointer 
structure( 
entries(80) 
byte); 
insert 
text 
index 
word; 


do 
insert 
text 
index 
= 
0 to 
(how 
many 
- 
1); 


th 
out-segment.message 
(insert 
text 
index) 


- 
dummy.entries 
(insert=text=index); 


end; 


do 
while 
insert 
text 
index 
< 
79; 
th_out 
segment.message 
(insert 
text 
index) 


= 
space; 
insert 
text 
index 
insert 
text 
index 
+ 
1; 


end; 


inter 


189 
1 


190 
2 
191 
2 


192 
2 
193 
2 
194 
3 


195 
3 


196 
2 
197 
3 


198 
3 


199 
2 


201 
202 
203 
204 
205 


/**********************************************/ 
/* Move 
down 
line 
puts 
the 
required 
number 
of 
*/ 
/* line-feed-characters 
in 
the 
first 
~th 
*/ 
/* through 
29th 
character 
of 
the 
output 
*/ 
/* message. 
Each 
line 
is displayed 
on 
the 
*/ 
/* screen 
in 
its 
proper 
location. 
This 
allows 
*/ 
/* multiple 
tasks 
to 
access 
the 
screen 
*/ 
/* without 
having 
to 
blank 
the 
line 
each 
*/ 
/* 
time. 
This 
technique 
assumes 
each 
message 
*/ 
/* sends 
the 
cursor 
home 
each 
time. 
*/ 
/**********************************************/ 


declare 
skip 
lines 


declare 
move-down 
line 
index 
word; 
word; 


if 
skip 
lines> 
0 then 
do 
move 
down 
line 
index 
= 
0 
th 
out 
segment.line 
~ndex 
- 
lTne_feed; 
- 
end; 


to 
(skip 
lines 
- 
1); 
(move_down_line_index) 


do 
move 
down 
line 
index 
= 
skip 
lines 
to 
23; 
th 
out 
segment~line 
index 
(move 
down 
line 
index) 


- 
null; 
- 


/***********************************************/ 
/* 
SEND 
REJECT 
MESSAGE 
is 
called 
by 
INPUT 
*/ 
/* 
PARAMETERS.- 
It 
just 
sends 
a 
reject 
message 
*/ 
/* to 
the 
CRT 
to 
inform 
the 
user 
that 
the 
*/ 


/* answer 
the 
user 
gave 
was 
not 
valid. 
*/ 


/***********************************************/ 


SEND_REJECT_MESSAGE: 
PROCEDURE; 


call 
move 
down 
line 
(21); 


text 
length 
= 
size(reject_message); 


insert 
text 
pointer 
= 
@reject 
message; 


call 
insert-text 
(insert 
text 
pointer, 
text_length) 
call 
display_line; 
-- 


/*************************************************/ 
/*************************************************/ 
/** 
The 
following 
procedures 
are 
the 
primary 
**/ 
/** 
working 
procedures 
called 
by 
the 
supervisor 
**/ 
/** 
procedure 
and 
its 
called 
procedures. 
**/ 


/*************************************************/ 
/*************************************************/ 


209 
210 


211 
212 
213 


215 
216 


217 
218 
219 


221 
222 
223 


/************************************************/ 
/* 
PURGE 
MAILBOX 
removes 
all 
tokens 
from 
*/ 
/* a mailbox. 
The 
purpose 
is 
to 
remove 
segments 
*/ 
/* waiting 
for 
processing 
by 
one 
of 
the 
tasks 
*/ 
/* 
if 
the 
operator 
has 
specified 
an 
abort 
*/ 
/* 
request. 
If 
the 
segment 
deletion 
was 
*/ 
/* successful, 
PURGE 
MAILBOX 
updates 
the 
*/ 
/* 
segment 
deleted 
tally. 
*/ 
/************************************************/ 


declare 
mailbox 
to_purge 


declare 
for 
110 
milliseconds 


declare 
message_received 
literally 
'OBH'; 


literally'oH'; 


declare 
contents 
token 


declare 
purge 
dummy 
mbx 


declare 
purge=status 


token; 
token; 
token; 


do 
while 
purge 
status 
= message 
received; 


contents 
token 
= 
rqSreceiveSmessage 
(~ailbox 
to 
purge, 
for 
110 
milliseconds, 


@purge_dummy_mbx, 
@purge_status); 


if 
purge 
status 
= message 
received 
then 
do; 
- 
- 
call 
rq~deleteSsegment 
(contents 
token, 
i<lpurge_status); 


segment 
deleted 
tally 
= 
- 
segment 
deleted 
tally 
+ 
1; 


purge 
status 
message=received; 


end; 


/***********************************************/ 
/* MONITOR 
MAILBOXES 
polls 
the 
*/ 
/* 
return 
th 
in mailbox 
and 
the 
*/ 
/* 
to 
s4pervlsor 
mailbox 
for 
messages. 
The 
*/ 
/* messages 
will-be 
abort 
(from 
the 
operator) 
*/ 
/* and 
FFT 
done 
or 
OUTPUT 
done 
if 
the 
runs 
are 
*/ 
/* not 
continuous. 
If 
the 
runs 
are 
not 
*/ 
/* continuous 
and 
an 
FFT 
done 
message 
is 
*/ 
/* 
received, 
MONITOR 
MAILBOXES 
will 
initialize 
*/ 
/* the 
OUTPUT 
task. 
- 
*/ 
/***********************************************/ 


inter 


2215 
2 
declare 
cannot 
wait 
literally 
'OOH '; 


227 
2 
declare 
done 
li terally 
'OFFH'; 


228 
2 
declare 
for 
400 
milliseconds 
literally 
I 28H' ; 


229 
2 
declare 
m~ssage=received 
literally 
I OOH '; 


230 
2 
declare 
not 
done 
li terally 
'OOH'; 


231 
2 
declare 
monitor 
dummy_ mbx 
token; 


232 
2 
declare 
monitor -token 
token; 


233 
2 
declare 
monitor -status 
token; 


234 
2 
declare 
done 
flag 
byte; 


235 
2 
declare 
monitor 
index 
word; 


236 
2 
done 
flag 
not 
done; 
- 
- 


237 
2 
segment 
deleted 
tally 
= 
0; 


238 
2 
call 
rq$sendSmessage 
(th 
in mbx, 
th 
in 
segment 
token, 
return 
th 
in mbx-; @status) 
; 
- - - 


239 
2 


240 
3 


241 
3 


242 
3 


243 
4 
244 
4 


245 
4 


2415 
4 


247 
4 
248 
4 


249 
4 


250 
4 


251 
4 


252 
3 
253 
3 
254 
4 


255 
4 


256 
4 
257 
5 


258 
5 


do 
while 
done 
flag 
= 
not 
done; 
/* Check 
for 
operator 
input 
here. 
*/ 
monitor 
token 
= 
rqSreceiveSmessage 
(return 
th 
in mbx, 
for 
400 
milliseconds, 


@monitor 
dummy 
mbx, 
0monitor 
status); 


if monitor 
status 
= message 
received 
then 
do 
while-segment 
deleted 
tally 
< 


number 
of 
fft-data 
segments; 
call 
purge 
mailbox 
(to 
fft 
mbx); 
if 
segment-deleted 
tally 
<- 
number 
of 
fft 
data 
segments 
then 
call 
purge 
mailbox 
(to 
input 
mbx); 
if 
segment 
deleted 
tally < 
- 
number 
or 
fft 
data 
segments 
then 


call 
purge 
mailbox 
(to supervisor 
mbx); 


if 
segment 
deleted 
tally < 
- 
number 
or 
fft 
data 
segments 
then 
call 
purge 
maTlbox-(to 
output 
mbx); 


done 
flag 
= done; 
- 
- 
end; 
- 


if 
done 
flag 
not 
done 
then 
do; 
monitor 
token 
= 
rqSreceiveSmessage 
(to supervisor 
mbx, 
for 
400 
miiliseconds, 


@monitor 
dummy 
mbx, 
@monitor 
status); 


if monitor 
status 
~ 
message 
receTved 
then 


do; 
- 
- 
if 
parameters.continuous 
flag 
= 


run 
continuous 
then 
- 
call 
rqSsendSmessage 
(to 
input 
mbx, 
monitor 
token, 


no-response 
requested-;. 


@monitor 
status); 


259 
2nO 


264 
265 
266 
267 


269 
1 


270 
2 
271 
2 


272 
2 


273 
2 


274 
2 


275 
2 
276 
2 
277 
2 


278 
2 


283 
284 


do; 
call 
rqSdelete$segment 
(monitor 
token, 
@monitor 
status); 


segment 
deleted 
tally 
- 
= 
segment 
deleted 
tally 
+ 
1; 
if 
segment 
deleted 
tally 
= 
number-of 
fft 
data 
segments 
then 
done 
flag 
~ 
done; 
end; 
end; 
end; 


/************************************************/ 
/* 
SET 
SEGMENT 
initializes 
the 
common 
parameter 
*/ 
/* areas 
of 
the 
segment. 
The 
pointer 
to 
the 
*/ 
/* proper 
segment 
is 
set 
up 
by 
*/ 
/* 
INITIALIZE 
SEGMENTS. 
*/ 


/************************************************/ 


frame.samples 
per 
frame 
= 
128; 


frame.sample 
Tnterval 
-= parameters.actual 
interval; 
frame.frames 
to 
average 
-= parameters.actual 
frames 
to 
average; 


frame.continuous 
flag 
= 
parameters.contTnuous_flag; 


frame.this 
frame 
number 


frame.number 
samples 
missed 


frame.sample-pointer- 
frame. reset_flag 


DOH; 
DOH; 
• 


OOH; 
OOH; 


/************************************************/ 
/* INITIALIZE 
SEGMENTS 
creates 
the 
three 
FFT 
*/ 
/* data 
segments 
and 
calls 
SET 
SEGMENT 
for 
each 
*/ 


/* segment 
to 
initialize 
the 
common 
parameter 
*/ 
/* 
areas 
of 
the 
segments. 
*/ 
/************************************************/ 


frame_pointer_values.offset 
= 
0; 


frame 
segment 
one 
= 
rqScreateSsegment 
- 
-(size 
~28 
bytes, 
0status); 


frame 
pointer 
values.base 
frame 
segment 
one: 
call 
set_segment; 
-- 


inter 


285 
286 
287 


2fl8 
2 
289 
2 
290 
3 


291 
3 
292 
3 
293 
3 
294 
3 


295 
3 


296 
2 
297 
2 
298 
3 


299 
3 


300 
3 
301 
3 
302 
3 


303 
3 


304 
2 


frame. reset 
flag 
number 
of 
fft 
data 
segments 
call 
rqSsend$message 
(to 
input 
mbx, 
frame 
segment 
one, 
no=response_requested, 
@status); 


new 
fft 
run; 
1; - 


if 
parameters.actual 
frames 
to 
average> 
1 then 
do; 
frame 
segment 
two = 
rqScreateSsegment 
- 
(size 
528 
bytes, 
@status); 
frame 
pointer 
values.base 
= 
frame 
segment 
two; 
call 
set 
segment; 
-- 
number 
of 
fft 
data 
segments 
2; 
call 
rqSsendSmessage 
(to 
input. mbx, 
frame 
segment 
two, 
no=response_requested, 
~status); 


if 
parameters.actual 
frames 
to_average> 
2 then 
do; 
frame 
segment 
three 
= 
rqScreate$segment 
- 
-(size 
528 
bytes, 
@status); 
frame 
pointer 
values.hase 
- 
- 
= 
frame_segment 
three; 
call 
set 
segment; 
number 
of 
fft 
data 
segments 
= 
3; 
call 
rqSsendSmessage 
(to 
input 
mbx, 
frame 
segment 
three, 
no-response 
requested, 
@status); 


/***********************************************/ 
/* 
INPUT 
PARAMETERS 
contains 
thr~e 
procedures: 
*/ 
/* set 
question 
pointers, 
get 
answer, 
*/ 


/* 
and-verify 
answers. 
The 
INPUT 
PARAMETERS 
*/ 


/* 
loop 
consists 
of 
calls 
to 
these 
three 
*/ 
/* 
procedures 
and, 
as 
usual, 
exists 
at 
the 
end 
*/ 
/* 
of 
the 
procedure. 
*/ 


/***********************************************/ 


305 
1 
INPUT 
PARAMETERS; 
PROCEDURE; 
- 


301; 
2 
declare 
actual 
pointer 
pointer; 
307 
2 
declare 
-pointer 
pointer; 
answer 
308 
2 
declare 
-display 
pointer 
pointer; 
answer 
309 
2 
declare 
question 
pointer 
pointer; 
- 


310 
2 
declare 
answer 
actual 
value 
based 
actual 
pointer 
word; 
- 


311 
2 
declare 
answer 
overlay 
based 
- answer 
pointer 
structure( 
number 
of 
answers 
byte, 


313 
2 


314 
2 
315 
2 
3111 
2 
317 
2 
318 
2 
319 
2 
3'20 
2 


321 
2 


322 
2 


323 
2 


324 
2 
325 
2 
32fi 
2 
327 
2 
328 
2 
329 
2 


330 
2 


331 
3 


332 
4 
333 
5 
334 
5 
335 
5 
336 
5 
337 
5 


338 
5 


339 
4 
340 
5 


341 
5 
342 
5 


343 
5 


344 
5 


345 
5 


3411 
4 
347 
5 


348 
5 


349 
5 


350 
5 


length 
of 
answer(o) 
values-to-match(30) 
really=are("i) 


byte, 
byte, 
wo rd) 
; 


declare 
answer 
display 
based 
- 
answer 
display 
pointer 
structure( 


characters(S) 
byte); 


declare 
answer 
byte 
index 


declare 
answer-index 


declare 
answer-match 


declare 
byte 
match 


declare 
input 
byte 
index 


declare 
output 
byte 
index 


declare 
question 
number 


declare 
stop_byte 


byte; 
byte; 
byte; 
byte; 
byte; 
byte; 
byte; 
byte; 


declare 
ascii 
small 
g 


declare 
ascii=capital_G 


declare 
average 
entry 
point 


declare 
continuous 
entry 
point 


declare 
f.requency 
entry 
point 


declare 
match 
- 
- 


declare 
no 
match 


declare 
not 
negative 


declare 
nothing 
returned 


literally 
'067H'; 


literally 
'047H'; 


literally 
'0'; 


literally 
'48'; 


literally 
'58'; 


literally 
'OFFH'; 


1iterally 
'OOH'; 


literally 
'< 255'; 


literally'OOH'; 


do; 


text 
length 
si ze 
(frequency 
question); 


question 
pointer 
= 
@frequency 
question; 


answer 
pointer 
= 
0frequency 
answers 
data; 


actual-pointer 
= 
0parameters.actual-interval; 


answer-display 
pointer 
- 
- 
@parameters.frequency_answer; 


do; 
text 
length 
si ze 
(average 
question); 


question 
pointer 
= 
0average 
question; 
answer 
pointer 
= 
eaverage 
answers 
data; 
actual-pointer 
-- 
-= 
~parameters.actual 
frames 
to 
average; 
answer 
display 
pointer 
- 
- 
0parameters.frames 
to 
average_answer; 


do; 
text 
length 
size 
(continuous 
question); 


question 
pointer 
= 
0continuous 
question; 


answer 
pointer 
- 
~continuous 
answers 
data; 


actual=pointer 
0parameters~continuous_flag; 


inter 


352 
353 


351) 
357 
358 


359 
360 
31)1 


367 
31)8 


answer 
display 
pointer 
- 
@parameters.continuous_flag_answer; 
end; 
end; 


get_answer: 
procedure; 


/* 
First 
display 
the 
question 
to 
be 
answered 
*/ 


/* 
by 
the 
operator. 
*/ 


call 
insert 
text 
(question_pointer, 
text 
length); 
call 
move 
down 
line 
(19); 
~ 
call 
dispTay_lTne; 


/* Then 
blank 
the 
line 
below 
for 
an 
answer 
line. 
*/ 


call 
blank 
line; 
call 
move 
down 
line 
(20); 
call 
dispTay_lTne; 


call 
rq$send$message 
(th 
in mbx, 
th 
in 
segment 
token, 
return 
th 
in mbx~ 
@status) 
; 
th_in_segment 
token 
= 
rq$receTveSmessage 
- 
(return 
th 
in mbx, 
wait 
forever, 
@dummy-mbx, 
~status); 
- 
th 
in 
segment 
pointer 
values.base 
- 
- 
- 
th_Tn_segment 
token; 


/* 
If 
there 
is 
no 
message 
returned 
then 
send 
*/ 
/* a 
reject 
message. 
*/ 


if 
th 
in 
segment.actual 
= 
nothing 
returnen 
then 
call 
send 
reject_message; 


/* Otherwise 
it 
is 
time 
to 
check 
the 
response 
*/ 
/* against 
the 
possible 
answers. 
*/ 


else 
do; 
answer_match 
= 
no_match; 


answer 
index 
= 
answer_overlay.number_of_answers; 


/* Start 
a 
loop 
to 
check 
all 
of 
the 
*/ 
/* 
possible 
answers. 
*/ 


intel 


380 
381 
382 


383 
384 
385 


38<) 
387 


do 
while 
(answer 
match 
no 
match) 
and 
(answer-index 
> 
0); 


/* Set 
the 
starting 
point 
for 
the 
*/ 
/* 
byte 
by 
byte 
compare. 
*/ 


/~ 
Set 
the 
stopping 
point 
for 
*/ 
/* 
the 
compare. 
*/ 


stop_byte 
= 
answer 
byte 
index 
- 
answer 
overlay.length 
of 
answer 


(answer_index 
- 
1); 
- 


/* Start 
with 
a 
"match" 
so 
we 
can 
*/ 
/* check 
until 
"no 
match" 
occurs. 
*/ 


byte_match 
= match; 


/* Set 
starting 
point 
at 
the 
right 
end 
*/ 


/* of 
the 
input 
data 
(allows 
us 
to 
*/ 


/* 
ignore 
leading 
blanks 
and 
the 
*/ 


/* 
ending 
carriage 
return). 
*/ 


/* Scan 
the 
bytes 
until 
all 
pertinent 
*/ 


/* ones 
are 
checked 
or 
a 
"no 
match" 
*/ 


/* occurs. 
*/ 


do 
while 
(byte 
match 
= 
match) 
and 
(answer 
byte 
index> 
stop 
byte); 
if 
(input 
byte 
index 
not 
negative) 
then 
do;- 
- 
if 
th 
in 
segment.message 
(input-byte 
index) 
= 
answer 
overlay.values 
to 
match 
(answer 
byte 
index)- 
- 
then 
byte 
match 
match; 
else 
byte-match 
no_match; 


end; 
- 
else 
byte 
match 
= 
no_match; 


answer 
byte 
index 
input 
byte 
Index 
end; 
- 
- 


answer 
byte 
index-I; 


input_byte 
Index 
-1; 


/* A 
"match" 
at 
this 
point 
means 
ALL 
*/ 


/* 
bytes 
matched. 
*/ 


if 
byte 
match 
= match 
then 
do; 


inter 


390 
391 


392 
393 


397 
398 
399 
400 


/ 401 
402 


405 
400 
407 


answer 
actual 
value 
~ 
answer 
overlay. 
really 
are 
(answer 
index 
- 
1); 
- 
answer_match 
= match; 


/* 
Insert 
displayable 
values 
for 
*/ 
/* 
later 
display. 
*/ 


answer 
byte 
index 
= 
4; 
input_byte_Tndex 
= 
(answer 
index*5)-1; 


do 
while 
answer 
byte 
index 
not 
negative; 
answer 
~is~lay.~haracters- 
-(answer 
byte 
index) 
= 
answer 
overlay~values 
to 
match 
(input 
byte 
index); 
input 
byte 
index 
- 
= Tnput-byte 
index 
- 
1; 
answer 
byte 
index 
answer-byte_index 
- 
1; 


/* 
We 
got 
a match, 
so 
be 
sure 
the 
*/ 


/* 
reject 
message 
line 
is 
blanked. 
*/ 


call 
move 
down 
line 
(21); 
call 
blank 
1 ine; 
call 
display_line; 
end; 


/* 
If 
no 
match, 
then 
let's 
compare 
the 
*/ 


/* 
input 
with 
the 
next 
possible 
answer. 
*/ 


else 
answer 
index 
= 
answer 
index 
- 
1; 
end; 
/* 
If 
we 
got 
a match, 
then 
we 
can 
move 
on 
*/ 


/* 
to 
the 
next 
question. 
*/ 


if 
answer 
match 
= match 
then 
question_number 
= 
question_number 
+ 
1; 


/* 
Otherwise 
we 
have 
to 
check 
for 
an 
*/ 


/* 
abopt 
request 
of 
:99'. 
*/ 


else 
do; 
input 
byte 
index 
= 
th 
in 
segment.~ctual-2; 


if 
(th 
in segment.message(input 
byte 
index) 


- 
~ 
ascii 
9) 
and 
(th 
in_segment.message 
(input_byte 
index 
- 


ascii_9) 
then 


inter 


408 
409 
410 
411 
412 
413 


414 
415 
416 


419 
420 


421 
422 
423 


425 
426 


427 
428 


47.9 
430 


/* Abort 
requests 
are 
valid, 
so 
blank 
*/ 


/* 
the 
reject 
message 
line 
and 
reset 
*/ 


/* 
the 
question 
number 
so 
we 
start 
*/ 
/* 
asking 
allover. 
*/ 


do; 
question 
number 
= 
1; 
call 
move 
down 
line 
(21); 
call 
blank 
line; 
call 
display 
line; 
end; 
- 
else 


/* 
But 
if 
nothing 
matched 
and 
the 
*/ 


/* answer 
was 
not 
an 
abort 
request, 
*/ 


/* 
then 
we 
have 
to 
ask 
the 
operator 
*/ 


/* 
to 
try 
again 
on 
this 
question. 
*/ 


call 
send 
reject_message; 
end; 
end; 


text 
length 
size 
(status 
line 
one); 


call-insert 
text 
(~status 
line_one, 
text_length); 


input 
byte 
index 


stop 
byte 
- 


do 
output 
byte 
index 
~ 
frequency 
entry 
point 
to 
stop 
byte; 
th 
out 
segnent.message 
(output 
byte 
index) 
= 
parameters.frequency 
answer 
(Input-byte 
index); 


input 
byte 
index 
= Tnput 
byte 
index 
+ I; 
end; 
- 
- 
- 
- 


0; 
frequency_entry 
point 
+ 
4; 


call 
move 
down 
line(19); 


call 
display_lTne; 


/* We 
have 
sent 
the 
first 
line, 
now 
it 
is 
time 
*/ 
/* 
to 
get 
the 
second 
1ine. 
*/ 


text 
length 
= 
size 
(status 
line 
two); 
call-insert 
text 
(@status_Iine 
two, 
text_length); 


inter 


431 
432 
433 


435 
436 


437 
438 
439 


442 
443 


44h 
447 


448 
449 


450 
451 
452 
453 


45J! 
455 
451j 


input 
byte 
index 
stop 
byte 
do 
output 
byte 
index 
~ 
average 
entry 
point 
to 
stop 
byte; 
th 
out 
segment.message 
(output 
byte-index) 
parameters.frames 
to 
average-answer 
(input 
byte 
index); 
- 
input 
byte-index 
input 
byte 
index 
+ 
1; 
end; 
- 
- 
- 
- 


0; 
average_entry 
point 
+ 
4; 


/* The 
continuous 
answer 
is 
different--we 
have 
*/ 
/* to 
decide 
if 
we 
have 
continuous 
runs 
or 
*/ 


/* single 
runs, 
and 
insert 
those 
words 
in 
the 
*/ 


/* display 
line. 
*/ 


input 
byte 
index 
= 
0; 
stop 
byte 
- 
= continuous 
entry 
point 
+ 
15; 
if 
parameters.continuous 
flag 
run 
continuous 
then 
- 
do 
output 
byte 
index 
~ 
continuous 
entry 
point 
to 
stop 
byte; 
th 
out 
segment.message 
(output 
byte 
index) 


contTnuous 
runs 
(input 
byte 
Tndex); 
input 
byte 
index 
input 
byte 
index 
+ 
1; 
end_; 
- 
- 
- 
else 
do 
output 
byte 
index 
~ 
continuous 
entry 
point 
to 
stop 
byte; 
th 
out 
segment.message 
(output 
byte 
index) 


single 
run 
(input 
byte 
index); 
- 
input 
byte 
index 
=-input 
byte 
index 
+ 
1; 
end; 
- 
- 
- 
- 


/* Then 
send 
the 
message 
and 
wait 
for 
a 
response 
*/ 
/* from 
the 
operator. 
*/ 


call 
move 
down 
line(20); 
call 
display_lTne; 


text 
length 
= 
si ze 
(go 
ahead 
question); 
call 
insert 
text 
(@go ahead 
question, 
text 
length); 


call 
move 
down 
line 
(7.1); 
- 
call 
display~lTne; 


call 
blank 
line; 
call 
move 
down 
line(22); 
call 
display_ITne; 


call 
rq$send$message 
(th 
in mbx, 
th 
in 
segment 
token, 
return 
th 
in mbx~ 
~status) 
; 
th 
in 
segment 
token 
- 
- 
- 
~ 
rq$receive$message 


inter 


464 
465 
466 


469 
470 
471 
472 
473 
474 
475 
476 
477 


478 
479 
480 


(return 
th 
in mbx, 
wait 
forever, 


@dummy-mbx, 
~status); 
- 


th 
in 
segment 
pointer 
values.base 
- 
~ 
th 
in 
segment 
token; 


input 
byte_index 
= 
th_in_segment.actual 
- 
2; 


/* Check 
for 
a 
"g" 
or 
"G" 
(we aren't 
fussy). 
If */ 
/* we 
got 
it, 
let's 
quit 
asking 
the 
selection 
*/ 
/* questions 
and 
go. 
If 
not, 
we 
have 
to 
start 
*/ 
/* 
at 
question 
1 again 
rather 
than 
try 
to 
find 
*/ 
/* out 
which 
of 
his 
or 
her 
answers 
wasn't 
*/ 
/* acceptable. 
*/ 


if 
(th 
in 
segment.message 
(input 
byte 
index) 
= 
ascii 
small 
g) 
or 
- 
(th 
in 
segment.message 
(input 
byte 
index) 
- 
- 
= 
ascii 
capital-G) 
then; 


else 
question_number 
=-0; 
- 


call 
blank 
1 ine; 


call 
move 
down 
line 
(21); 


call 
display_line; 


/* * * * * * * * * * * * * * * * * * * * * * * * */ 
/* 
As 
usual, 
the 
actual 
INPUT 
PARAMETERS 
control 
*/ 
/* 
loop 
is 
at 
the 
end. 
*/ 
/* * * * * * * * * * * * * * * * * * * * * * * * */ 


/* 
All 
we 
do 
is get 
the 
next 
question, 
ask 
the 
*/ 
/* question 
until 
it 
is 
answered 
successfully, 
*/ 
/* ask 
all 
of 
the 
questions, 
then 
check 
all 
of 
*/ 
/* the 
answers. 
If 
the 
operator 
doesn't 
like 
*/ 
/* the 
set 
of 
answers, 
we 
loop 
through 
them 
*/ 
/* 
again. 
First 
we 
make 
sure 
the 
reject 
mess~ge 
*/ 
/* line 
and 
other 
pertinent 
lines 
start 
out 
*/ 
/* 
blanked. 
*/ 


call 
blank 
line; 


call 
move 
down 
line 
(18); 


call 
display 
line; 


call 
move 
down 
line 
(21); 


call 
display 
lIne; 


call 
move 
down 
line 
(22); 


call 
display 
line; 


call 
move 
down 
line 
(23); 


call 
display_line; 


input 
loop: 
do 
while 
question 
number 
< 
3; 
call 
set 
question 
pointers; 


call 
get=answer; 
- 


inter 


481 
3 
end; 


482 
2 
call 
verify 
answers; 
483 
2 
if 
question -number 
0 then 
go to 
input 
loop; 
= 
- 


485 
2 
END 
INPUT 
PARAMETERS; 
- 


481'; 
1 


487 
2 
488 
2 
489 
2 
490 
2 
491 
2 
492 
2 
493 
2 
494 
2 


495 
2 


/*************************************~**********/ 
/* 
INITIALIZE 
TASKS 
initializes 
the 
INPUT 
TASK 
*/ 
/* and 
the 
FFT 
TASK. 
If 
the 
FFT 
runs 
are 
to 
be 
*/ 
/* continuous, 
INITIALIZE 
TASK 
also 
initializes 
*/ 
/* the 
OUTPUT 
TASK. 
If 
the 
runs 
are 
not 
*/ 


/* continuous, 
the 
OUTPUT 
TASK 
is 
initialized 
*/ 
/* by 
MONITOR 
MAILBOXES. 
*/ 
/***********************************************/ 


declare 
declare 
d.eclare 
declare 
declare 
declare 
declare 
declare 


hardware 
interrupt 
level 
3 
no 
data 
segment 
- 
nucleus-allocated 
stack 
software 
priority-level 
~7 
software-priority-level 
130 
software-priority-level 
131 
stack 
size 
512 
- 
task 
flags- 


literally'038H'; 
literally'OOH'; 
literally 
'OOH'; 
literally 
'{)7'; 
literally 
'130'; 
literally 
'131'; 
literally 
'512'; 
literally'OOH'; 


input 
task 
token 
= 
rqScreateStask 
(software 
priority 
level 
67, 
@input 
task, 
no 
data 
segment, 
nucleus 
allocaterl-stack, 
stack 
sTze 
512, 
task 
flags, 
@status); 


call 
rqScatalogSobject 
(supervisor 
job, 
input 
task 
token, 
@(lO,'INPUT 
TASK'), 
~status); 


fft 
task 
token 
= 
rqScreateStask 
(software 
priority 
level 
131, 
@fft 
task, 
no 
data 
segment, 
nucleus 
allocated 
stack, 
stack 
sTze_5l2, 
task_flags, 
@status); 


call 
rqScatalogSobject 
(supervisor 
job, 
fft 
task 
token, 
@(8,'FFT 
TASK'), 
@status); 


output 
task 
token 
= 
rq~createStask 
(software 
priority 
level 
130, 
~output 
task, 
no 
data 
segment, 
nucleus 
allocated 
stack, 
stack_sTze_512, 
task 
flags, 
~status); 


call 
rqScatalogSobject 
(supervisor 
job, 
output 
task 
token, 
@(ll,'OUTPUT 
TASK'), 
@status); 


inter 


502 
1 


503 
2 


504 
2 
505 
2 
506 
2 


507 
2 
508 
2 


509 
2 
510 
2 
511 
2 


512 
2 
513 
2 
514 
3 
515 
3 
SIn 
3 


517 
2 


/************************************************/ 
/* 
Initial 
screen 
displays 
the 
initial 
two 
*/ 
/* 
lines 
on 
the 
screen 
and 
sends 
blank 
lines 
*/ 
/* 
for 
all 
the 
other 
lines 
of 
the 
first 
screen. 
*/ 
/************************************************/ 


call 
move 
down 
line(O}; 
call 
blank 
line; 


call 
display_line; 


call 
move 
down 
line(l}; 


text 
length 
= size(header 
line 
one}; 


insert 
text 
pointer 
= 
@header 
line 
one; 


call 
insert-text 
(insert 
text-pointer, 
text 
length); 
call 
display_line; 
-- 


call 
blank 
line; 
do 
initial-screen 
index 
= 
2 to 
23; 
call 
move 
down-line 
(initial 
screen 
index); 
call 
display 
line; 
end; 
- 


/*****************************************/ 
/* INITIALIZE 
BUFFERS 
takes 
care 
of 
the 
*/ 
/* initialization 
required 
for 
general 
*/ 
/* SUPERVISOR 
TASK 
start 
up. 
*/ 
/*******************~*********************/ 


return 
th 
in mbx 
rqScreateSmailbox 
Tqueue 
fifo, 
@status}; 


call 
rqScatalogSob]ect 
(supervisor 
job, 
return 
th 
in mbx, 


@(9,'SUP 
TH 
IN'), 
@status); 
return 
th 
out 
mbx 
= 
rqScreateSmailbox 
- 
(ijueue fifo, 
@status); 


call 
rqScatalogSobTect 
(supervisor 
job, 
return 
th 
out 
mbx, 


@(lO,'SUP 
TH 
OUT'), 
@status}; 
to_input_mbx 
= rqScreateSmailbox 
(queue 
fifo, 
0status); 


call 
rqScatalogSobject 
(supervisor 
job, 
to 
input 
mbx, 
~(12,'TO 
INPUT 
MBXT), @status}; 


to 
fft 
mbx 
= 
rqScreateSmailbox 
(queue_priority, 
@status); 


inter 


531 
2 


532 
2 


533 
2 


534 
2 


535 
2 


536 
2 
537 
2 


538 
2 
539 
2 


540 
2 


541 
2 


542 
2 
543 
2 


544 
2 
545 
2 


546 
2 
547 
3 


548 
3 


549 
2 


call 
rqScatalogSobject 
(supervisor 
job, 
to 
fft 
mbx, 
@(lO,'TO 
FFT 
MBX')~ 
@status); 


to_output_mbx 
= 
rqScreateSmailbox 
(queue 
priori ty, 
@status); 


call 
rqScatalogSobject 
(supervisor 
job, 
to 
output 
mbx, 
@(lO,'TO 
OUT 
MBX')~ 
@status); 


to 
supervisor 
mbx 
= 
rqScreateSmailbox 
- 
(queue 
priority, 
@status); 
call 
rq$catalogSobject 
(supervisor 
job, 
to 
supervisor_mbx, 


@(lO,'TO 
SUP 
MBX')~ 
@status); 


root_job_token 
= 
rqSget$taskStokens 
(root job, 
@status); 
th 
out 
mbx 
= 
rqSlookup$object 
(root 
job 
token, 
@(ll,'RQTHNORMOUT'), 


wait-forever, 
@status); 


th 
in mbx 
~ 
rqSlookup$object 
(root 
job 
token, 
@(lO,'RQTHNORMIN'), 


wait=forever, 
@status); 


th 
in 
segment 
token 
= 
rqScreateSsegment 
(size 
120 
bytes, 
@status); 


call 
rq$catalog$ob}ect- 
(supervisor 
job, 
th 
in 
segment 
token, 


@(lO,'S 
THIN 
SEG')~ 
@status);- 
th 
in 
segment 
pointer 
values.offset 
= 
0; 


th-in-segment-pointer-values.base 
- 
- 
- 
= th 
in 
segment 
token; 
th 
in 
segment.function 
- 
- 
= 
th 
read; 


th=in=segment.count 
-= 82; 


th_out_segment_token 
rq$createSsegment 
(size 
120 
bytes, 
@status); 


call 
rqScatalogSob}ect- 
(supervisor 
job, 
th 
out 
segment 
token, 


@(ll,'S 
THOUT 
SEG'), 
@status);- 


th 
out 
segment 
pointer 
values.offset 
= 
0; 


th-out-segment-pointer-values.base 
- 
- 
- 
= 
th-out 
segment 
token; 
th 
out 
segment. 
function 
- 
th-write; 


th=out=segment.count 
- 
Ill; 


do 
general 
index 
= 
0 to 
2; 


th 
out 
segment.home 
chars 
(general 
index) 


- 
- 
cursor 
home-chars 
(general-index); 


/*************************************************/ 
/* At 
last, 
the 
SUPERVISOR 
TASK! 
All 
it 
does 
is */ 


/* call 
other 
procedures 
to 
initialize 
the 
*/ 
/* 
screen, 
input 
the 
parameters, 
clean 
up the 
*/ 
/* old 
FFT 
segments 
from 
the 
mailboxes, 
set 
up 
*/ 
/* new 
segments, 
create 
the 
tasks, 
and 
then 
wait 
*/ 
/* for 
messages 
from 
the 
operator 
(abort) 
or 
*/ 
/* other 
tasks 
(FFT 
or 
OUTPUT 
done) • 
*/ 
/*************************************************/ 


553 
554 
~all 
initial 
screen; 


call 
initialTze_tasks; 


556 
557 
558 


call 
input 
parameters; 
call 
initi~lize 
segment.; 
call 
monitor_maTlboxes; 


END 
SUPERVISOR_TASK; 


END 
SUPERVISOR_MODULE; 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


1197 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


1032H 
aOaOH 
a084H 
a024H 


4141)D 
OD 
132D 
31)D 


ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
INPUT 
TASK 
MODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:input.OBJ 


COMPILER 
INVOKED 
BY: 
plm8n 
:Fl:input.p86 


$title('TNPUT 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980') 
$large 
debug 


INPUT 
TASK 
MODULE: 
do; 
$include(:fl:nucprm.ext) 
$SAVE 
NOLIST 


99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
III 
112 
113 
114 
115 
1111 
117 
118 
119 
120 
121 
122 
123 


/* The 
following 
two 
tokens, 
the 
FFT 
sample 
*/ 
/* segment 
format, 
and 
the 
root 
job 
directory 
*/ 
/* form 
the 
entire 
interface 
for 
this 
task 
with 
*/ 
/* 
the 
rest 
of 
the 
system. 
*/ 


declare 
to 
input 
mbx 


declare 
to-fft 
mbx 
token 
external; 


token 
external; 


declare 
declare 
declare 
declare 
declare 
declare 
declare 


declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 


ascii 
mask 
carriage 
return 
done 
- 
first 
loop 
forever 
frames 
to 
process 
entry 
hardware 
Tnterrupt 
level 
3 
- 
- 
literally 
'0038H'; 


interrupt 
task 
created 
literally 
'OFFH'; 


interrupt-task-not 
created 
literally 
'OOH'; 


latch 
the-data 
- 
literally 
'040H'; 


line 
feed 
literally 
'OAH'; 


new 
fft 
run 
literally 
'OFFH'; 


no 
response 
requested 
literally 
'OOH'; 


no-data 
segment 
literally 
'OOH'; 


not 
done 
I 
literally 
'DOH'; 


not-first 
loop 
literally 
'DOH'; 


not-valid 
literally 
'OOH'; 


null 
literally 
'DOH'; 


processed 
so 
far_entry 
literally 
'33'; 


queue 
fifo 
literally 
'DOH'; 


root job 
literally'03H'; 


run 
continuous 
literally 
'OFFFFH'; 


sample 
LSB 
literally 
'0081H'; 


sample-MSB 
literally 
'0080H'; 


size 
2-bytes 
literally 
'2'; 


size-120 
bytes 
literally 
'120'; 


supervisor 
job 
literally 
'DOH'; 


th 
write 
literally 
'OS'; 


thIS 
is 
the 
interrupt 
task 
literally 
'OIH'; 


timer 
one 
port 
literally 
'OOD2H'; 


timer-mode 
control 
port 
literally 
'OODI1H'; 


valid- 
- 
- 
literally 
'OFFH'; 


literally'30H'; 
literally'ODH'; 
literally 
'OFFH'; 


literally 
'OFFH'; 


literally 
'while 
I'; 


literally 
'50'; 


125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
Un 
137 
138 
139 


144 
145 
146 
147 
148 
149 


declare 
data 
segment 
token 
declare 
dummy 
mbx 
- 
declare 
from 
Interrupt 
task 
mbx 
declare 
handler 
dummy 
mbx 
- 
declare 
handler-status 
declare 
interrupt 
status 
declare 
interrupt-task 
token 
declare 
interrupt-message 
token 
declare 
output 
buffer 
token 
declare 
return-mbx 
- 
declare 
root 
job 
token 
declare 
signal 
interrupt 
token 
declare 
status- 
- 
declare 
to 
interrupt 
task 
mbx 
declare 
th-out 
mbx 
- 


token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 


declare 
sample 
input 
data 
structure( 
LSB 
- 
byte, 
MSB 
byte) 
at 
(~sample_data); 


declare 
timer 
values 
structure( 
LSB 
- 
byte, 
MSB 
byte) 
at 
(@current_timer_value); 


declare 
done 
flag 
declare 
firs£ 
input 
loop 
flag 
declare 
frames 
receIved 
declare 
general 
index 
declare 
interrupt 
task 
flag 
declare 
sample_valid 
- 


declare 
timer 
threshold 


byte; 
byte; 
byte; 
byte; 
byte; 
byte; 


declare 
converted 
value 
structure( 
first 
digIt 
byte, 
second_digit 
byte) ; 


/* The 
following 
declare 
is 
for 
the 
home 
*/ 
/* characters 
for 
the 
Hazeltine 
terminals. 
*/ 
/* The 
sequence 
is 
tilde, 
OC2. 
*/ 


intel 


Hi2 
11)3 


declare 
output 
buffer 
pointer. 
values 
structure 
( 
offset 
- 
word~ 
base 
wo rd) 
at 
(@output_buffer_pointer) 
; 


declare 
output 
buffer 
based 
output 
buffer_pointer 
structure( 
function 
word, 
count 
word, 
exception 
code 
word, 
actual 
- 
word, 
home 
chars(2) 
byte, 
line-index(?4) 
byte, 
character 
(3D) 
byte); 


declare 
data 
segment 
pointer 
values 
structure( 
offset 
- 
word, 
base 
word) 
at 
(@data 
segment_pointer); 


/* The 
following 
is 
the 
FFT 
data 
segment 
format. 
*/ 


declare 
data 
segment 
based 
data 
segment 
pointer 
structure 
( 
-- 
samples 
per 
frame 
word, 
sample 
Tnterval 
word, 
frames-to 
average 
word, 
continuous 
flag 
word, 
this 
frame-number 
word, 
number 
samples 
missed 
word, 
sample-pointer- 
word, 
reset 
flag 
word, 
sample(256) 
integer); 


declare 
input 
status 
line(30) 
byte 
data 
(' - 
The 
INPUT 
TASK 
has 
processed 
I 


I 
frames 
out 
of 
frames 
to' 
, average. 
I) 
; 


FAST,INPUT 
HANDLER: 
PROCEDURE 
(FFT 
SEGMENT 
POINTER) 
EXTERNAL; 
DECLARE 
FFT 
SEGMENT 
POINTER 
POINTER; 
END 
FAST_INPUT_HANDLER; 


/************************************************/ 
/* 
SLOW 
INPUT 
HANDLER 
is 
an 
interrupt 
procedure 
*/ 


/* 
that 
receives 
an 
interrupt 
when 
the 
8253 
*/ 
/* interval 
timer 
counts 
to 
zero. 
The 
8253 
is 
*/ 
/* free 
running, 
so 
it 
starts 
counting 
from 
the 
*/ 


/* top 
again. 
The 
8253 
counter 
is 
tested 
*/ 


/* 
in 
a 
polling 
fashion 
to 
be 
sure 
it 
reads 
the 
*/ 
/* 
sample, 
which 
resets 
the 
conversion, 
*/ 


/* at 
a 
precise 
time. 
This 
aids 
in 
removing 
*/ 


inter 


165 
lfi6 


167 
168 


169 
170 
171 
172 
173 


174 
175 
176 


177 
178 


179 
180 


/* jitter 
from 
the 
sample 
intervals. 
When 
all 
*/ 


/* 
of 
the 
samples 
have 
been 
taken, 
*/ 


/* 
SLOW 
INPUT 
HANDLER 
calls 
signal 
interrupt, 
*/ 


/* which 
lets-the 
INTERRUPT_TASK 
procedure 
know 
*/ 


/* 
the 
buffer 
is 
full. 
*/ 


/************************************************/ 


SLOW_INPUT_HANDLER: 
PROCEDURE 
INTERRUPT 
59 
PUBLIC; 


/* 
First 
set 
the 
sample 
to 
not 
valid 
(we have 
*/ 


/* to 
be 
past 
the 
timer 
threshold 
before 
the 
*/ 


/* sample 
becomes 
valid) 
• 
*/ 


sample 
valid 
timer_loop: 


/* Make 
the 
timer 
value 
stable 
and 
read 
it. 
*/ 


output 
(timer 
mode 
control 
port) 
= 
latch 
the 
data; 


timer 
values.LSB 
-input 
(timer 
one 
port); 
- 
timer=values.MSB 
= 
input 
(timer=one=port); 


/* If 
it 
is 
not 
past 
the 
threshold, 
then 
some 
*/ 


/* 
future 
sample 
will 
be 
valid. 
*/ 


if 
current 
timer 
value> 
timer 
threshold 
then 
do; 
sample 
valid 
= valid; 
goto 
tTmer 
loop; 
end; 


/* We 
get 
to 
the 
else 
only 
if we 
are 
past 
the 
*/ 
/* timer 
threshold. 
*/ 


else 


do; 
sample 
input 
data.LSB 
= 
input(sample 
LSB); 
sample=input=data.MSB 
= 
input(sample=MSB); 


/* If 
the 
sample 
is valid, 
we 
must 
have 
come 
*/ 


/* in 
before 
the 
threshold 
so 
we 
know 
we 
*/ 


/* sampled 
as 
close 
to 
the 
right 
time 
as 
*/ 


/* 
possible. 
*/ 


if 
sample 
valid 
= valid 
then 
do; 


/* However, 
we 
want 
to 
ignore 
the 
first 
*/ 


/* sample 
(which 
was 
started 
a 
long 
*/ 


/* 
time 
ago). 
*/ 


if 
first 
input 
loop 
flag 
= 
first 
loop 
then 


first 
Tnput 
loop 
flag 
not 
first 
loop; 


else 
- 
- 
- 
-- 


do; 


182 
5 


183 
5 


184 
5 
185 
4 


186 
3 
187 
4 


188 
4 
189 
4 
190 
3 
191 
3 


/* 
/* 
/* 


data 
segment.sample 
(data 
segment.sample 
pointer) 
= sample 
data; 
- 
data 
segment.sample 
pointer 
- 
data_segment:sample_pointer+l; 


end; 
else 
do; 
data 
segment.number 
samples 
missed 
~ 
data 
segment.number 
samples 
missed+l; 


data 
segment.sample 
pointer 
= 
0; - 
end; 
- 
- 
sample 
valid 
not_valid; 
end; 
- 


If 
we 
are 
done, 
we 
have 
to 
let 
the 
*/ 


INPUT 
TASK 
know 
the 
buffer 
is 
full. 
*/ 


Otherwise, 
we 
wait 
for 
the 
next 
interrupt. 
*/ 


if 
data 
segment.sample 
pointer 
>= 
data 
segment:samples 
per 
frame 
then 
call 
rqSsTgnalSinterrupt 
- 
(hardware 
interrupt 
level 
3, 
@handler=status) 
; 
else 
call 
rqSexitSinterrupt 
(hardware 
interrupt 
level 
3, 
@handler=status); 
- 


/*************************************************/ 
/* INTERRUPT 
TASK 
exists 
because 
if 
an 
interrupt 
*/ 
/* task 
goes-to 
sleep, 
the 
level 
of 
the 
*/ 


/* interrupt 
task, 
interrupt 
handler, 
and 
lower 
*/ 


/* levels 
remain 
disabled. 
In 
order 
to 
prevent 
*/ 


/* this 
from 
happening 
in 
this 
application, 
this 
*/ 


/* task 
notifies 
the 
INPUT 
TASK 
that 
the 
buffer 
*/ 


/* is 
full. 
INPUT 
TASK 
disables 
Level 
3 and 
*/ 


/* returns 
the 
token 
to 
INTERRUPT 
TASK. 
*/ 


/* INTERRUPT 
TASK 
will 
then 
call 
wait 
interrupt, 
*/ 


/* enabling 
lower 
levels. 
Since 
INPUT 
TASK 
*/ 


/* disabled 
Level 
3, 
no 
Level 
3 interrupts 
will 
*/ 
/* be 
serviceq 
until 
Level 
3 is 
enabled 
by 
*/ 
/* 
INPUT 
TASK. 
*/ 
/* 
*/ 


/* 
NOTE 
THAT 
PLM/8h 
REQUIRES 
THE 
USE 
OF 
THE 
*/ 


/* BUILT 
IN 
INTERRUPTSPTR 
PROCEDURE 
TO 
OBTAIN 
*/ 


/* THE 
PROPER 
INTERRUPT 
PROCEDURE 
ENTRY 
POINT. 
*/ 
/* 
*/ 


/*************************************************/ 


intel 


205 
206 


207 
208 
209 


210 
211 


call 
rqSset$interrupt 
(hardware 
interrupt 
level 
3, 
this 
is the 
interrupt 
task, 
INTERRUPTSPTR(SLOW 
INPUT 
HANDLER), 
no_data 
segment, 
~Tnterrupt 
status); 


call 
rq$waitSinterrupt 
(hardware 
interrupt 
level 
3, 
@interrupt 
status); 


call 
rqSsendSmessage 
(from 
interrupt 
task 
mbx, 
interrupt 
message 
token, 
to_interrupt_task=mbx, 
@interrupt_status); 


interrupt 
message 
token 
= 
rqSreceive$message 
(to 
interrupt 
task 
mbx, 
wait 
forever, 
@dummy_mbx, 
@interrupt_status); 


/************************************************/ 
/* 
CONVERT 
DIGITS 
is 
a 
small 
procedure 
for 
*/ 
/* 
convertTng 
a hex 
number 
into 
an 
ASCII 
*/ 


/* 
number, 
with 
the 
advance 
knowledge 
that 
the 
*/ 


/* hex 
number 
will 
be 
less 
than 
99 
decimal 
(in 
*/ 


/* 
this 
case, 
less 
than 
32 
decimal). 
*/ 


/************************************************/ 


converted 
value.first 
digit 
converted=value.second_digit 
ascii 
mask; 
ascii=mc3sk; 


done 
flag 


do 
while 
done 
flag 
not 
done; 
not=done; 


/* The 
problem 
here 
is 
we 
need 
to 
check 
for 
*/ 


/* 
a 
negative 
value 
when 
we 
have 
BYTE 
values 
*/ 


/* 
which 
are, 
hy 
definition, 
positive 
and 
*/ 


/* 
mudulo 
256. 
So 
we 
adapt 
by 
checking 
for 
*/ 


/* 
> 
200 
decimal, 
which 
should 
mean 
the 
*/ 


/* 
value 
has 
"wrapped" 
around 
zero. 
If 
it 
*/ 


/* 
has, 
we 
can 
get 
our 
previous 
value 
back 
*/ 


/* 
by 
aooing 
10. 
*/ 


if 
value 
to 
convert 
< 
~OO 
then 
converted=value.first_digit 


inter 


212 
213 
214 


215 
216 
217 


• 


219 
1 


220 
2 


221 
2 


222 
2 


223 
2 


7.24 
2 


225 
2 


226 
2 


227 
2 


228 
2 


229 
2 


230 
2 


else 
do; 
value 
to 
convert 
= value 
to 
convert 
+ 
10; 


converted 
value.second 
dTgit 
= converted 
value.second 
digit 
+ 
value 
to 
convert; 
- 


done 
flag 
= 
done;- 
- 
end; 


end; 


/**********************************************/ 
/* 
SEND 
STATUS 
converts 
the 
current 
frame 
*/ 
/* number 
into 
ASCII 
and 
stuffs 
it 
into 
the 
*/ 
/* previously 
initialized 
status 
line. 
Then 
*/ 
/* SEND 
STATUS 
sends 
the 
status 
line 
to 
the 
*/ 
/* termTnal 
handler 
and 
waits 
for 
the 
segment 
*/ 
/* to 
be 
returned. 
*/ 
/**********************************************/ 


output 
buffer.character 
(processed 
so 
far 
entry) 


- 
= converted 
value.fTrst-digit; 
output 
buffer.character 
(processed 
so 
far-entry+l) 


- 
converted_value.second_digit; 


output 
buffer.character 
(frames 
to 
process 
entry) 


- 
= 
converted 
value. first 
digit; 
output 
buffer.character 
(frames 
to 
process 
entry+l) 


- 
~ 
converted_value.second=digit; 


call 
rq$send$message 
(th out 
mbx, 
output_buffer 
token, 


return-mbx, 
@status); 


output 
buffer 
token 
- 
rq$receive~message 
(return 
mbx, 
wait 
forever, 
@dummy=mbx, 
~status); 


/***********************************************/ 
/* INPUT 
DATA 
selects 
the 
fast 
or 
slow 
input 
*/ 
/* handler, 
initializes 
the 
8253 
timer 
as 
*/ 
/* necessary, 
and 
calls 
the 
appropriate 
input 
*/ 


inteJ 


/* handler. 
Please 
note 
the 
values 
of 
the 
*/ 


/* 
intervals 
sele;;:tedfor 
sampling 
are 
*/ 
/* scaled 
by 
~0/~4 
so 
the 
actual 
frequency 
*/ 
/* output 
of 
the 
128 sample 
FFT 
algorithm 
will 
*/ 
/* match 
up with 
the 
base 
10 x axis 
labels. 
*/ 
/* Base 
10 doesn't 
map 
too 
well 
to a binary 
*/ 


/* x-axis 
that 
runs 
from 
1 to 
~4. 
*/ 
/***********************************************/ 


231 
1 
INPUT 
DATA: 
PROCEDURE; 
- 


232 
2 
declare 
LSB 
120Hz 
interval 
literally 
'058H'; 
233 
2 
declare 
MSB-120Hz-interval 
literally 
'002H' ; 


2311 
2 
declare 
LSB-t;QOHz-interval 
literally 
'078H'; 


235 
2 
declare 
MSB-fiOOHz-interval 
literally 
'OOOH'; 


236 
237 


239 
240 
241 
242 
243 
244 
245 
24~ 
247 


/* The 
8253 
timer 
is running 
at 
143.~ 
Khz, 
or 
*/ 
/* <;.5 microseconds 
per 
count. 
We 
have 
to 
*/ 
/* 
restart 
the 
sampling 
process 
precisely, 
so */ 
/* we 
count 
down 
after 
the 
interrupt 
to be 
*/ 
/* sure 
we 
are 
synchronized. 
In this 
case, 
*/ 
/* we have 
a 
300 microsecond 
window 
after 
the 
*/ 
/* 
interrupt 
to get 
the 
sample. 
300 
*/ 
/* microseconds 
is roughly 
112 times 
t;.5 
*/ 
/* microseconds. 
*/ 


declare 
threshold 
for 
120Hz 
declare 
threshold 
for-~OOHz 
literally'022EH'; 
literally'0048H'; 


declare 
a 390h 
microsecond 
interval 
literally'OF42H'; 
dec;are 
five 
places 
literally'S'; 
declare 
onucl"eus allocated 
stack 
literally 
'OOH'; 
declare 
shift 
integer 
right 
literally 
'SAL'; 
declare 
software 
priority 
level 
0 literally 
'OO~'; 


declare 
software-priority-level 
fifiliterally 
'~6'; 
declare 
stack 
size 
512 
- 
literally 
'512'; 
declare 
task 
71ags- 
literally 
'DOH'; 


declare 
this 
task 
literally 
'OOH'; 
declare 
timer 
m~de 
control 
word 
literally 
'74H'; 


/* The 
first 
thing 
we 
do 
is start 
the 
conver- 
*/ 
/* sions. 
We 
don't 
care 
about 
the 
first 
*/ 
/* data 
since 
we 
are 
going 
to 
ignore 
it. 
Each 
*/ 
/* time 
we 
read 
both 
bytes 
of 
the 
present 
*/ 
/* 
converted 
value, 
we 
start 
the 
next 
*/ 
/* 
conversion. 
This 
initialization 
will 
*/ 
/* prepare 
for 
the 
real 
data 
gathering. 
*/ 


251 
2 
252 
2 
253 
3 


254 
3 


255 
3 


256 
4 


257 
4 


258 
4 


259 
4 


260 
3 


2fil 
4 


262 
4 


263 
4 


264 
4 


21)5 
3 


266 
3 


267 
3 
21)8 
4 


271 
272 


if 
data 
segment.sample 
interval> 
391 
then 


do; 
- 
- 
output 
(timer 
mode 
control 
port) 


= 
timer 
mode 
control 
word; 


if data 
segment.sample 
interval 
~ 
a 
3906 
microsecond 
interval 
then 


do'; 
timer 
threshold 
= threshold 
for 
120Hz; 
output 
(timer 
one 
port) 
= 
LSB 
120Hz 
interval; 
output 
(timer 
one 
port) 
MSB 
120Hz 
interval; 
end; 
else 
do; 
timer 
threshold 
= threshold 
for 
"OOHz; 


output 
(timer 
one 
port) 
= 
LSB 
fiOOHz interval;- 


output 
(timer 
one 
port) 
= MSB_"OOHZ 
interval; 
end; 
first_input_loop_flag 
= 
first_loop; 


if 
interrupt 
task 
flag 
= 
interrupt_task 
not 
created 
then 


do; 


interrupt 
task 
token 
= 
rqScreateStask 


(software 
priority 
level 
"", 
@interrupt 
task, 
no 
data 
segment, 


nucleus 
allocated 
stack,- 


stack_sTze_5l~, 
task_flags, 
0status); 


call 
rqScatalogSobject 
(supervisor 
job, 
interrupt 
task 
token, 


@(12,'INTERRUPTTSK'), 
@status); 


interrupt 
task 
flag 
interrupt_task_created; 


end; 
else 
call 
rqSenable 
(hardware_interrupt_level_3, 
@status); 


/* Now 
we 
wait 
until 
the 
slow 
handler 
*/ 
/* 
fills 
the 
buffer. 
*/ 


signal 
interrupt 
token 
rqSreceiveSmessage 


(from 
interrupt 
task 
mbx, 
wait_forever, 


@dummy_mbx, 
@status); 


/* 
If 
we 
get 
the 
token, 
we 
know 
the 
buffer 
*/ 
/* 
is 
full, 
so 
we 
disable 
level 
3 
*/ 


278 
3 


279 
3 
280 
03 


281 
3 


282 
2 
283 
3 


284 
3 


285 
2 
286 
3 
287 
3 


288 
2 


\ 


290 
291 


call 
rqSdisable 
(hardware 
interrupt_level 
3, 
@status); 


/* And 
return 
the 
token 
so 
the 
*/ 
/* INTERRUPT 
TASK 
can 
enable 
lower 
*/ 


/* interrupt-levels. 
*/ 


call 
rqSsendSmessage 
(to 
interrupt 
task 
mbx, 
signal 
interrupt 
token, 
no 
response_requested, 
Pstatus); 


end; 


else 


do; 


/* The 
fast 
INPUT 
handler 
must 
sample 
at 
/* precise 
intervals 
that 
do 
not 
allow 
/* variable 
interrupt 
latency. 
Therefore 


/* we 
raise 
the 
priority 
level 
to 
O--the 


/* highest--and 
just 
sample 
in 
a 
polling 


/* fashion 
until 
the 
buffer 
is 
filled. 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


call 
rqSsetSpriority 
(this 
task, 
software 
priority 
level 
0, 
@status) 
; 
- 


call 
FAST 
INPUT 
HANDLER 
(data 
segment 
pointer); 


call 
rqSsetSpriority 
- 
- 
(this 
task, 
software 
priority 
level 
~~, 
@status); 
- 
- 


do 
general 
index 
= 
0 to 
127; 


data 
segment.sample 
(general 
index) 


shift 
integer 
right 
(data 
segment.sample 
(general 
index), 


- 
five_places) 
; 


do 
general 
index 
= 
128 
to 
255; 


data 
segment.sample 
(general 
index) 
end; 
- 


/**********************************************/ 
/* UPDATE 
FRAME 
NUMBER 
just 
updates 
the 
frame 
*/ 
/* number-parameter 
on 
the 
data 
segments. 
*/ 
/**********************************************/ 


data 
segment.number 
samples 
missed 


data=segment.sample=pointer- 


intel 


294 
295 
296 
297 
298 


299 
300 


if 
frames 
received 
= data 
segment.frames 
to 
average 
then 
frames_received 
=-0; 
- 


if 
data 
segment. 
reset 
flag 
do; 
- 
- 
frames 
received 
= 
0; 
data 
segment.reset 
flag 
end; 
- 
- 


frames 
received 
frames 
received 
+ 
1; 
data_segment.this 
frame 
number 
frames 
received; 


/***********************************************/ 
/* INITIALIZE 
BUFFERS 
takes 
care 
of 
the 
usual 
*/ 


/* trivia 
of 
setting 
up 
the 
pointers, 
creating 
*/ 


/* the 
return 
mailbox, 
looking 
up 
the 
terminal 
*/ 


/* handler, 
and 
all 
that 
other 
small 
garbage. 
*/ 
/***********************************************/ 


return 
mbx 
= 
rq$createSmailbox 
(queue 
fifo, 
t'lstatus); 
call 
rqScatalogSobject 
(supervisor 
job, 
return 
mbx, 
@(9,'I 
RET-MBX'), 
I<Istatus); 


from 
interrupt 
task 
mbx 
= 
rq~createSmailbox 


(queue 
fito, 
~status); 
call 
rqScatalogSobject 
(supervisor 
job, 
from 
interrupt 
task 
mbx, 
@(12,'FM 
INTSK 
MBX')~ 
@status); 


to 
interrupt 
task 
mbx 
rqScreate~mailbox 
(queue 
tifo, 
@status); 
call 
rqScatalogSobject 
(supervisor 
job, 
to 
interrupt 
task 
mbx, 
~(12,'TO 
INTSK 
MBX'), 
@status); 


interrupt_message 
token 
= 
rqScreateSsegment 
(size 
2-bytes, 
@status); 


call 
rqScatalogSo5ject 
(supervisor 
job, 
interrupt 
message 
token, 
~(lO,'INTTSK 
MSG'), 
@status); 


interrupt 
task 
flag 
-= 
interrupt_task_not_created; 


output 
buffer 
token 
= 
rqScreateSsegment 
(si ze 
120 
bytes, 
~status); 
call 
rqScatalogSobject 
(supervisor 
job, 
output 
buffer 
token, 


@(lO,'I 
BUFF 
SEG'), 
@status); 


inter 


314 
2 
315 
2 


31'5 
2 
317 
2 
318 
2 
319 
3 


320 
3 


321 
2 


322 
3 


323 
:1 


324 
2 


325 
3 


326 
3 


327 
2 


328 
3 


329 
3 


330 
2 


331 
2 


332 
2 


333 
2 


output 
buffer 
pointer 
values.offset 
0; 
output-buffer-pointer-values.base 
- 
= output 
buffer 
token; 
output 
buffer.function 
= 
tn 
write; 
output-buffer.count 
= 110; 


do 
general 
index 
= 
0 to 
'5; 
output 
buffer.home 
chars 
(general 
index) 
- 
cursor 
nome 
chars 
(general_index); 


do 
general 
index 
= 
0 to 
21; 
output 
buffer.line 
index 
(general 
index) 


- 
line 
feed; 


do 
general 
index 
= 
22 
to 
23; 
output 
buffer.line 
index 
(general 
index) 
- 
= 
null; 
- 


do 
general 
index 
= 
0 to 
78; 
output 
buffer.character 
(general 
index) 


- 
input_status_line 
(general 
index); 


root 
job 
token 
= 
rqSgetStaskStokens 
(root job, 
@status); 
th 
out 
mbx 
= 
rqSlookup$object 
(root 
job 
token, 
~(ll,'RQTHNORMOUT'), 


wait=forever, 
@status); 


/**********************************************/ 
/* The 
actual 
INPUT 
TASK 
begins 
here. 
It 
*/ 
/* 
initializes 
the 
buffers 
to 
begin 
things, 
*/ 
/* 
then 
waits 
forever 
for 
the 
FFT 
sample 
*/ 
/* 
segment. 
It 
then 
samples 
the 
data, 
fills 
*/ 
/* 
the 
FFT 
data 
segment, 
and 
sends 
it 
to 
the 
*/ 
/* 
FFT 
TASK. 
The 
INPUT 
TASK 
then 
updates 
its 
*/ 
/* 
status 
line, 
sends 
it 
to 
the 
terminal 
*/ 
/* handler, 
and 
returns 
to 
the 
mailbox 
to 
*/ 
/* 
wait 
forever. 
*/ 
/**********************************************/ 


334 
1 
INPUT 
TASK: 
PROCEDURE 
PUB LIC; 
- 


335 
2 
call 
initialize 
buffers; 
- 


336 
2 
data 
segment 
pointer 
values.offset 
0; 
- 
- 


337 
2 
do 
forever; 


intel' 


/* wait 
forever 
for 
an 
FFT 
data 
segment 
at 
*/ 


/* 
the 
to 
input_mbx. 
*/ 


data 
segment 
token 
= 
rqSreceiveSmessage 
(to 
input 
mbx, 
wait 
forever, 
@dummy 
mbx, 
~status); 
data 
segment 
pointer 
values.base 
~ 
data_segment_token; 


call 
update 
frame 
number; 


call 
input_data; 
340 
341 


call 
rq$send$message 
(to_fft_mbx, 
data 
segment 
token, 
no 
response 
requested, 
@status); 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
754 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 
OF 
PL/M-8~ 
COMPILATION 


070BH 
OOOOH 
n03r;H 
OO:?AH' 


1803D 
OD 
54D 
42D 


inter 


MCS-86 
MACRO 
ASSEMBLER 
FSTINP 
ISIS-II 
MCS-86 
MACRO 
ASSEMBLER 
V2.1 
ASSEMBLY 
OF 
MODULE 
FSTINP 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:FSTINP.OBJ 


ASSEMBLER 
INVOKED 
BY: 
asm86 
:fl:fstinp.aA~ 


LOC 
OBJ 
LINE 


1 
2 
3 


4 
5 


6 


7 


8 


9 


10 


11 
12 


13 


14 


15 


16 


17 


18 


19 


20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 


FAST 
INPUT 
HANDLER 
for 
APNOTE 
110, 
OCTOBER 
1980 


FAST 
INPUT 
HANDLER 
is 
an 
assembler 
routine 
that-runs 
at 
priority 
level 
0 and 
simply 
drives 
an 
analog 
to 
digital 
convertor 
and 
stuffs 
the 
samples 
int~ 
a data 
segment 
until 


all 
of 
the 
samples 
have 
been 
taken. 
FAST 
INPUT 
HANDLER 
has 
passed 
to 
it 
the 
address 
of 
the 
data 
segment, 
in which 
the 
offset 
is 


known 
to 
be 
zero. 
FAST 
INPUT 
HANDLER 
returns 
nothing 
to 
the 
callTng 
routine. 


FAST 
INPUT 
HANDLER 
provides 
the 
proper 
timing 


for 
sampling 
at 
a 
39, 
78, 
and 
391 
microsecond 
intervals 
using 


timed 
loops 
of 
software 
instructions. 
In 
order 
to 
provide 


an 
FFT 
without 
large 
amounts 
of 
jitter, 
the 
sample 
interials 
must 


be 
uniform 
in 
time. 
iRMX 
86 
cannot 
guarantee 
this 
uniformity 
due 


to 
its 
real 
time 
design, 
so this 
routine 
takes 
complete 
control 
of 
the 
processor 
for 
the 
(39 
times 
128) 
4.9 
milliseconds 
or 


(78 
times 
128) 
9.9 
or 
(391 
times 
128) 
50 milliseconds 
required 


to 
complete 
a 
frame 
of 
128 
samples. 


AX 
- general 
CX 
- loop 
delay 
counter 
BX 
- stack 
index 


DX 
- sample 
value 


BP 
- stack 
SP 
- stack 


01 
- offset 
index 
into 
FFT 
SI 
- not 
used 


data 
segment 


DS 
- base 
for 
FFT 
data 
segment 


OOSO 
0081 
00 DE 
0002 
0002 
010E 


DODO 
(20 
0000 
) 


50 


???? 
51 
52 
53 
54 
55 
56 
57 
5S 


1)4 
0000 
65 
~n 
0000 
IE 
67 


0001 
55 
liS 


; 
.********************************************** 
, 


; 
ASSUME 
DS:FAST 
INPUT 
DATA, 
SS:STACK, 
CS:FAST=INPUT=CODE, 
ES:NOTHING 


; 
SAMPLE 
LSB 
SAMPLE-MSB 
FIRST 
PASS 
SAMPLE 
INCREMENT 
SAMPLE-INTERVAL 
SAMPLE-MAX 


; 
FAST 
INPUT 
DATA 


; 
FAST 
INPUT 
DATA 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


OOSOH 
00A1H 
14 
2 
2 
270 


SEGMENT 
WORD 


PUBLIC 
'DATA' 


SEGMENT 
PARA 
PUBLIC 
'CODE' 


; 
PUSH 
OS 
PUSH 
BP 
; SAVE 
BP 
IN 
STACK 
MOV 
BP, 
SP 
; SET 
BP 
TO 
STACK 
POINTER 
MOV 
OS, 
rBP + 
10] 


; PUT 
BASE 
OF 
SAMPLE 
SEGMENT 
IN 
DS 


MOV 
DI, 
SAMPLE 
INTERVAL 
; OX 
IS 
USED 
TO 
INDEX 
INTO 
THE 
DATA 
SEGMENT 


MOV 
AX, 
OS: (DI] 


; SET 
AX 
TO 
SAMPLE 
INTERVAL 
PARAMETER 


MOV 
DI, 
FIRST 
PASS 


; RESET 
DI 
TO-FIRST 
SAMPLE 
- 
14 
CMP 
AX, 
39 
; IF AX = 
39, 
SET 
LOOP 
VALUE 
TO 
9--LOOP 
JZ 
SET 
39 
US 


; TAKES ABOUT 
1 US PER DECREMENT 
CMP 
AX, 7A 
; IF AX = 78, SET LOOP VALUE TO 22--BASIC 
JZ 
SET 78 US 
CYCLE-IS-13 
US, PLUS 
(22 X 3) = 79 
US 
R 78 
MOV 
LOOP VALUE, 
12n 
; 391 IS-ONLY ONE LEFT-13 + 
(12nX3) 


= 391 
79 
JMP 
INPUT LOOP 
; 
R 80 
SET 39 US: 
MOV 
LOOP_VALUE, 
9 
;-TIMING IS BY SOF~NARE--SET 
DELAY COUNT 
JMP 
INPUT LOOP 
; 
SET 78 US: 
MOV 
LOOP_VALUE, 
?2 ; 
INPUT-LOOP: 
MOV 
CX, 
LOOP VALUE 
; USE CX TO KEEP TRACK OF-DELAY 
84 
IN 
AL, SAMPLE LSB 
; SET AL TO LSB OF INPUT SAMPLE 
85 
MOV 
DL, AL 
; PUT THE LSB IN DL 
(8 BIT XFERS ONLY) 
86 
IN 
AL, SAMPLE MSB 
; SET AL TO MSB OF INPUT SAMPLE 
87 
; THIS RESTARTS 
SAMPLE 
PROCESS 
88 
MOV 
DH, AL 
; PUT AL IN DH TO COMPLETE 
THE VALUE 


003D 83FFOE 89 
CMP 
DI, FIRST PASS 
; WE WANT TO SKIP 
THE FIRST SAMPLE 


0040 7408 
90 
JZ 
SKIP INPUT 


0042 83C702 
91 
ADD 
DI, SAMPLE 
INCREMENT 
; INCREMENT DI-BY 
2 
92 
MOV 
DS: rDIl, 
DX 
; PUT SAMPLE DATA IN SEGMENT 


0047 EB0990 
93 
JMP 
DELAY 
; AND JUMP TO SOFTWARE 
DELAY LOOP 


004A 83C702 
94 SKIP INPUT: 
ADD 
DI, SAMPLE 
INCREMENT 
; INCREMENT 
DI BY 2 
- 
95 
Nap 
; AND Nap FIVE TIMES FOR EVEN TIMING 
9" 
Nap 
97 
Nap 
98 
Nap 
99 
Nap 
100 DELAY: 
Nap 
; THIS Nap ADDS 
3 CLOCKS 
PER DECREMENT 


0053 EOFD 
101 
LOOPNZ DELAY 
; DEC CX AND LOOP--l.5 US PER DECREMENT 


0055 81FFOErrl 102 
CMP 
DI, SAMPLE MAX 
; COMPARE 
DI TO SEE IF WE ARE DONE 


0059 75D~ 
103 
JNE 
INPUT LOOP 
; IF NOT,-GO 
BACK FOR ANOTHER 
SAMPLE 
104 
POP 
SP 
; OTHERWISE 
POP BP, DS, AND RETURN 
POP 
DS 
RET 
4H 


OOIF EBI090 
0022 C70600000900 


0028 ES0790 
002B C70600001600 
0031 8BOEOOOO 


81 
R 
82 
R 83 


004E 90 
004F 90 
0050 90 
0051 90 
0052 90 


005e 
IF 
105 


005D CA0400 
IOn 


107 


108 
FAST INPUT HANDLER 
ENDP 
109 
; 
110 
FAST INPUT CODE 
ENDS 
III 
112 
END 


Both- the RAM and ROM-based configurations will be 
discussed in this appendix. They are essentially identical 
processes. In either case, the fir~t step is to define a map 
of system memory. Once the map is known, the follow- 
ing sequence is suggested for locating code in memory: 


I) Reserve memory OH to 03FFH for the Nucleus in- 


terrupt vector. 


2) If the system is RAM based and the code is loaded. 


by the 
iSBC 957A 
Monitor, 
reserve 
locations 


03FFH to 07FFH for the monitor's use. 


3) Configure each of the necessary portions 
of the 


iRMX 86 Operating 
System and locate them se- 


quentially in memory. 


4) For a RAM-based development system, allow 2K of 


RAM for the system Root Job. Placing the Root 
Job after the portions of the iRMX 86 Operating 
System, which are relatively fixed in size during 
development, and before the development code will 
give the Root Job a fixed address. This will prevent 
having to move the Root Job and reconfigure the 
system when the development code grows. For final 
EPROM-based 
systems, the Root Job should be 


placed after the development code. 


5) Link and locate each of the application code mod- 


ules sequentially in memory. 


6) Define the RAM available to the system. 


7) Define memory NOT available to the system. This 


includes 
application 
code, 
EPROM, 
and 
non- 


existent memory within the 1 megabyte address 
space. 


8) Create the configuration file using the address maps 
produced by the locate steps and the memory map 
defined in steps 6 and 7. 


9) Create the Root Job from this configuration file. 


10) Load and test the system in RAM. 


11) If the system has been fully debugged, load the code 


into EPROM and test the final system. 


The above steps are necessary for both the RAM devel- 
opment system and the final EPROM system. Convert- 
ing this application from RAM to EPROM requires re- 
configuring the Nucleus to include only those systems 
calls required by the application, substituting the Ter- 
minal Handler Job for the Debugger Job, removing any 
remaining system calls to catalog objects for debugging, 
and remapping 
the system to the EPROM 
address 


space. The memory maps for the development and final 
application are shown in Figures C-I and C-2. 


(RESERVED) 


RESET 
VECTOR 


ISBC 
957A 
MONITOR 
EPROM 


SYSTEM 
RAM 


EXPANSION 


APPLICATION 
DATA 


EXPANSION 


APPLICATION 
CODE 


ROOT 
JOB 


DEBUGGER 


NUCLEUS 


iSBC 
957A 
MONITOR 


INTERRUPT 
VECTOR 


ADDRESS 


FFFFFH 


} 
EPROM 


FFFFOH 


FDOOOH 
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EXISTENT 


20000H 


QFFFFH 


OEDSOH 


OEC10H 


OEB07H 


OCQBQH 
RAM 


OBACOH 


05330H 


OOOOH 


OOOH 


OH 


(RESERVED) 


RESET 
VECTOR 


UNUSED 
EPROM 


ROOT 
JOB 


APPLICATION 
CODe 


TERMINAL 
HANDLER 
CODE 


NUCLEUS 
CODE 


SYSTEM 
RAM 


ROOT 
JOB 
DATA 


APPLICATION 
DATA 


TERMINAL 
HANDLER 
DATA 


NUCLEUS 
STACK 


NUCLEUS 
DATA 


INTERRUPT 
VECTOR 


ADDRESS 


FFFFFH 


FFFFOH 


fF5COH 


EPROM 


FD3DOH 


FCAOOH 


F8000H 


} 
NON- 
EXISTENT 


Q4000H 


OB90H 


OBSOH 


OA58H 
RAM 
O99OH 


0800H 


400H 


OH 


System configuration is a straightforward 
but exacting 


process. As with any such processes, there are some 
hints that can make development easier. In addition to 
care in locating the Root Job in memory, users should 
fix the initialization job entry point and the data RAM 
addresses. 


The Intel PLiM 
86 programming 
language does not 


allow a procedure to be used until after it has been de- 
clared. This requires the initialization procedure to be 
declared after all the other procedures. Since the initial- 
ization is last, changing the other procedures will change 
the location of the initialization procedure. If the system 
entry point changes, the system must be reconfigured. 
The moving entry point can be circumvented by writing 
a separate initialization task. The Root Job will create 
only the initialization task which will then initialize the 
system jobs. The initialization task entry point is fixed 
by linking it ahead of the other application tasks and by 
not changing the initialization task during dvelopment. 
The actual system entry points will be bound to the ini- 
.tialization task during linking and locating. The linking 
and locating steps are a natural consequence of chang- 


ing the application code, so binding the fixed system en- 
try point is done automatically 
during development. 


The fixed initialization task entry point is used in the 
configuration 
file, giving the Root Job an unchanging 


system entry point. 


The remaining moving target during development is the 
RAM area for data and stack use. If the data and stack 
RAM is located before or after the application code, 
with enough extra memory in between for growth dur- 
ing development, the data and stack locations can stay 
constant. Fixing both the application entry point and 
the locations of the stack and data segments will allow 
development of the application code to proceed without 
requiring frequent reconfigurations. 


ARTICLE 
REPRINT 
AR-124 


Introducing the RMX/86™realtime, 
multitasking, 
16·bit operating system 


"Now we have a situation in which electronic intelligence is spreading to more and more 
places, and in addition, the application sophistication 
at each of these places is growing as well. 


So, when we multiply 
what it takes to program all the new microcomputer 
products so that 
they can be applied, and calculate what that means in terms of how many computer program- 
mers will be needed by 1990, we come out with a requirement 
for over one million computer 
programmers!" 
Excerpted from a speech by Andrew S. Grove, President, Intel Corporation, 


given before the New York Society of Security Analysts, January 24, 1980. 


A 


s 
production 
technologies 
such 
as VLSI (Very 


Large 
Scale 
Integrationj 
proliferate- 
with 
their 
greater 
levels 
of 
density-the 
use 
of 
low-cost 
microcomputer 
hardware 
to solve 
increasingly 
complex 
application 
problems 
has creat- 


ed a crisis 
in software. 
A partial 
solution 
to the 
pro- 


grammer 
shortage 
would"be 
the 
creation 
of "building 


blocks" 
for system 
development. 
It is this 
modular, 


building 
block 
concept 
upon 
which 
the RMX/86 
Op- 
erating 
System 
is constructed. 


This 
modular 
operating 
system 
for 
Intel 
I6-bit 
microcomputers 
allows 
custom 
operating 
systems 
to be 
assembled 
largely 
from 
off-the-shelf 
software 
com- 


ponents. 
Such 
systems 
when 
needed 
in OEM 
micro- 
computer 
applications, 
pose 
problems-rarely 
can 
an 
OEM afford man-years 
of effort to develop 
the intimate 


familiarity 
with 
the 
hardware 
that's 
needed 
to design 
executive 
software. 
But with 
Intel's 
RMX/86 
system 
he 


won't 
have 
to. 


In addition, 
this second-generation 
16-bit system 
adds 


. error handling 
flexible 
command-line 
decode, 
and other 
advanced 
OS capabilities 
to previous 
options 
available 


on the mature 
RMX/80 
package. 
All real-time 
multitasking 
systems 
require 
executive 
software 
to manage 
the 
resources 
shared 
by the 
pro- 
grams 
(CPU 
time, 
memory 
and 1/01. 
respond 
to inter- 
rupts 
and 
then 
allocate 
the 
resources 
according 
to 


established 
priorities. 
Normally, 
these 
functions 
are 


intermingled 
in an OS with 
higher-level 
system 
func- 
tions 
that often 
prove superfluous 
in microcomputer 
ap- 
plications. 


The 
RMX/86 
package 
combines 
all those 
required 
executive 
functions 
in 
a 
single 
module, 
called 
the 


nucleus. 
Other 
modules 
in the package 
tailor 
the execu- 
tive 
system 
to 
its 
application 
by adding 
higher-level 
operating 
system 
functions 
such 
as disk-file 
systems. 


The 
application 
programs 
and 
optional 
modules 
con- 
nect 
to the nucleus 
with 
simple 
software 
interfaces. 


Since 
the nucleus 
is essentially 
open-ended, 
it serves 


as the 
software 
foundation 
for expanding 
both 
higher- 
level operating 
system 
functions 
and varieties 
of appli- 
cation 
programs. 
Although 
most 
microcomputer 
appli- 
cations 
are dedicated, 
many 
do require 
such higher-level 
capabilities. 


The modular 
approach 
to system 
software 
fits in with 
the way most 
OEMs 
[and high-volume 
end users I apply 


single-board 
computers. 
They 
generally 
start 
with 
a 
minimum 
amount 
of hardware 
marketed 
at the lowest 


cost possible. 
Then, 
when 
their 
users 
are fully utilizing 


the original 
functions 
and are willing 
to buy more, 
the 


The RMX/86 Nucleus is the heart of the operating system and is 
surrounded by application, human interlace and input/output 
facilities. 


OEM adds functionality 
by increasing 
the executive 


facilities, application tasks and hardware-allowing 
the 
fastest turnaround 
possible. 


To see how the RMX/86 
operating 
system works, 
consider 
a typical example. 
Sayan 
OEM develops a 
factory 
heating 
and air-conditioning 
control 
system 


with a single-board computer, 
analog I/O, special con- 
trol devices and operator terminal. He uses the nucleus, 
and terminal handler modules, plus user tasks stored in 
EPROM. 


But suppose the OEM's customer 
wants to enhance 
the system with, say, disk storage. He simply adds a 
disk controller 
board and I/O 
system 
software. 
The 


original programs could also be made disk-resident. 
If 
the original application 
had been based on a conven- 
tional executive, 
extensive redevelopment 
would have 


been necessary. 


If, on the other hand, the application had used the full 
110 system from the start, initial sales would have suf- 
fered because the OEM's system would have been more 
costly. And if the software is not extendible, future sales 
are lost. 
The historic 
problem 
with conventional 
"general- 


purpose" operating systems is that they usually depend 
on hardware that the application 
would not otherwise 


need-for 
example, 
large disk systems while a typical 
OEM system 
uses no mass storage 
at all. Modular 


operating systems are designed to accommodate 
a diver.' 


sity of applications 
without 
undue hardware imposed 


on them. 


For an even closer fit with customers 
applications, 


the 
RMX I 86 modules 
closely 
parallel 
hardware 


modularity. 
Corresponding to the hardware, the RMXI 86 nucleus 


manages CPU, memory and I/O sources. When linked 
to optional 
modules 
it can support 
standard 
iSBC 


devices like consoles and disk controllers. 
Similarly, 


users may add device driver software modules for their 
custom peripherals. All software can reside in EPROM I 
ROM if mass storage is not available. 


The RMX/86 operating system is designed for config- 


uration, 
to user specification, 
on an Intellec develop- 


ment 
system. 
The same system supports 
application 
software development 
as well as linking and locating 


both high-level and assembly language. 


A real-time multitasking 
nucleus gives a program the 


means to monitor 
and control external events. Tasks 


running concurrently, 
using the services of the execu- 


tive are signaled 
with 
interrupts 
and the executive 


schedules resources for the tasks on the basis of priority. 
For example, 
a task trying to bring an oven's 
tem- 


perature under control should have a much higher pri- 
ority than a repon generating task. The nucleus' sched- 
uler decides whether 
a running 
task should be inter- 


rupted to process data from an interrupting 
device. 


The RMX/86 
nucleus 
makes 
event-driven 
priority 


scheduling possible by monitoring 
system states, deter- 


mining task requirements, 
allocating the resources and 


gathering 
the resources 
for reallocation 
after use has 


completed. 
Resources include CPU time, memory and 


I/O. 


As in most priority based systems, 
the highest-pri- 
ority task that's ready to run uses the CPU; others are 
put on a ready list. After servicing an interrupt, 
the 


nucleus returns the CPU to the highest-priority 
ready 


task. 


A memory manager, built into the nucleus, 
handles 


the 8086's megabyte 
addressing 
range, insuring 
that 


memory 
is used efficiently. The memory manager or- 


ganizes 
memory 
into a tree-structured 
hierarchy 
of 


pools according to each job's requirements, 
and pro- 
vides for allocation 
and deallocation 
of memory 
from 


these pools. When the nucleus or application tasks re- 
quire memory, the memory manager allocates it on the 
basis of segments 
that 
are multiples 
of 16-bytes (to 


65,536 bytes) corresponding 
to the 8086's segmented 


memory architecture. 


The RMX/86 nucleus provides three sets of facilities 


for tasks to communicate 
with one another. Each of the 


three is optimized for either data transfer, synchroniza- 
tion or mutual exclusion. 


Mailboxes are provided to allow tasks to send data, in 


the form of segments, 
to one another. 
Since each seg- 


ment 
is referenced 
by 
a description, 
of course, 
only 
pointers 
are moved 
rather 
than 
massive 
blocks 
of data. 
Semaphores 
offer low overhead 
mechanisms 
for syn- 
chronization 
operations. 
For 
example, 
one 
task 
can 


simply 
set 
a semaphore 
to 
tell 
another 
task 
that 
an 
event 
has happened 
("Analog 
data 
received''!. 


The 
third 
communication 
facility 
offers 
a unique 
mutual 
exclusion 
facility. 
Regions 
are defined 
as a body 
of code 
which 
manipulates 
a shared 
resource 
The 
RMX!86 
nucleus 
insures 
that 
while 
one task 
is manip- 
ulating 
the resource 
others 
don't 
inadvertantly 
affect it. 
All intertask 
communication 
functions 
are accessible 
with 
simple 
calls to the nucleus. 
For example, 
to access 
a mailbox 
the 
task 
simply 
names 
the 
mailbox 
desired. 
The 
programmer 
has 
no 
need 
to 
know 
the 
internal 
structure 
of the mailbox, 
since 
all functions 
are access- 
ible through 
easily 
programmed 
interfaces. 


Another 
RMX! 
86 
feature, 
exceptional-condition 


handling 
makes 
error 
handling 
simple 
rather 
than 
elusive. 
Programs 
can be designed 
to manage 
error con- 


ditions 
and 
take 
the appropriate 
corrective 
action 


First, 
there's 
an 
option 
to 
specify 
to 
the 
nucleus 
whether 
or not there 
should 
be any error handling 
for a 
particular 
task. 
A programmer 
can use a default 
handler 
to abort 
a task 
or he may 
program 
a specific 
course 
of 
action-for 
example, 
load a fresh 
copy 
of the 
program 
and try again. 
The 
exception-condition 
facilities 
also 
detect 
pro- 
gramming 
errors 
such as a wrong 
call to the nucleus 
and 
system 
problems, 
like 
insufficient 
memory. 
All-in-all 
the OEM will find that fault 
tolerance 
is no longer 
just a 
buzzword. 


Most 
microcomputers 
are 
used 
with 
a range 
of pe- 
ripheral 
devices, 
from 
serial 
lines 
to mass 
storage. 
The 
RMX! 
86 1/ 0 
system 
provides 
the 
user 
with 
a 
very general 
file concept; 
that 
of files as a data 
sink 
or 


source. 
The 
characteristics 
of specific 
storage 
medium 
dictate 
the access 
techniques 
for a given 
file. For exam- 
ple, 
a disk 
file may 
be accessed 
either 
in sequential 
or 
random 
fashion, 
while 
a file accessed 
over a serial 
link 
(USARTj 
must 
be processed 
serially. 
Using 
the data sink! 
source 
concept, 
the user can de- 
velop 
application 
programs 
without 
worrying 
about 
the 
physical 
characteristics 
of the device. 


Such 
device 
independence 
simplifies 
application 
pro- 
gramming 
and allows 
programs 
to be used 
with 
a vari- 
ety of devices. 
The 
RMX!86 
I/O 
system 
supports 
threc 
types 
of 
logical 
files: 
Physical 
files 
represent 
the 
lowest 
interfacc 
level 
which 
rctains 
its 
device-independent 
characteristics. 
Physical 
files 
provide 
a simple, 
consistent 
interface 
to 
all 
device 
drivers. 
OPEN, 
CLOSE, 
READ, 
WRITE, 


SEEK, and special 
instructions 
perform 
all desired 
I/O 
operations. 


Stream files provide 
a temporary 
data-transmission 


path 
between 
tasks. 
One 
task 
may 
write 
data 
to the 


stream 
file while 
another 
reads 
it. The 1/ 0 system 
per- 
forms 
the 
required 
synchronization 
and 
buffering. 
Stream 
files offer the user a simple 
mechanism 
for pass- 


ing data 
between 
tasks-one 
that 
remains 
consistent 
with 
other 
file 
options, 
thus 
allowing 
the 
user 
to 
simulate 
an external 
device 
while 
waiting 
for hardware 


to be built. 


Named files are used for the conventional 
data storage 
on 
mass-storage 
devices 
like 
floppy 
or hard 
disks 
for 


later 
access. 
However 
the 
RMX!86 
I/O 
system 
goes 
one step further 
by setting 
up a hierarchical 
directory 
of 


files. This feature 
allows 
the user to organize 
his files to 


be consistent 
with 
his application. 


The named-file 
system 
has another 
advantage: 
It per- 


mits 
file-access 
checking, 
so a user can decide 
which 
of 


his 
files he wants 
to protect 
and 
which 
to share 
with 
other 
users. 


Each 
of the 
file options 
can 
be configured 
indepen- 


dently; 
so that 
the user may 
select 
only 
the features 
he 


needs-nothing 
more. 


Furthermore, 
the RMX! 86 1/ 0 system 
is designed 
to 
allow 
the user to easily add his own device 
drivers 
to the 
system 
as the need 
arises. 
The 
RMX! 86 operating 
system 
was designed 
to offer 


the 
user 
a wide 
spectrum 
of convenient 
human 
inter- 
face 
functions. 
For example, 
the 
user 
of mass-storage 
systems 
is provided 
display 
directory 
and 
copy 
file 
utilities. 
Additionally, 
the 
OEM 
who 
needs 
his 
own 
interactive 
capability 
can 
either 
use 
the 
standard 
RMX!86 
facilities 
or easily 
extend 
the system's 
human 


interface 
routines 
to 
meet 
his 
specific 
application 
requirements. 


The 
software 
crisis 
can 
be overcome 
only 
by 
in- 


troducing 
a broad 
base of system 
software 
functionality 


into the market, 
allowing 
OEMs 
to concentrate 
on their 
area of expertise. 
Intel's 
RMX!86 
operating 
system 
takes 
a major 
stride 
forward 
in providing 
extendible, 
proven 
tools 
for OEMs 


to use 
in creating 
eustom 
operating 
systems 
for their 
application. 


The 
RMX! 
86 operating 
system 
thus 
provides 
the 
OEM 
with 
a powerful 
new 
system 
building 
block, 
en- 


hancing 
the 
productivity 
of system 
generation. 
New 
dynamic 
tools like the RMX! 86 operating 
system 
allow 
users 
to deliver 
their 
product 
into 
the 
marketplace 


much 
earlier, 
thereby 
capturing 
an 
important 
com- 


petitive 
advantage. 


Modular multitasking executive 
cuts cost of 16-bit-OS design 


A 
modular, 
real-time 
multitasking 
operating 
sys- 
tem for single-board 
computers 
allows custom 
operating 
systems 
to be assembled 
largely from off- 
the-shelf 
software 
components. 
Such systems, 
when 
needed 
in OEM single-board 
~C applications, 
pose 
problems-rarely 
can an OEM afford man-years 
of 
effort 
to develop the intimate 
familiarity 
with the 
hardware 
that's needed to design executive software. 


But with Intel's RMX/86 system for iSBC 86 single- 
board computers, 
he won't have to. 
In addition, 
this second-generation, 
16-bit system 
added error-handling, 
flexible command-line 
decode, 
and other advanced OS capabilities to previous options 
available 
on the older RMX/80. 


All real-time 
multitasking 
systems 
require 
ex- 
ecutive 
software 
not only to manage 
the resources 
shared by the task programs (CPU time, memory and 
I/O), but also respond to interrupts 
and then allocate 
the resources according to established 
priorities. Nor- 
mally, these functions are intermingled 
in an OS with 
higher-level 
system functions that often prove super- 
fluous in single-board 
computer 
applications. 
The RMX/86 OS package 
combines 
all those re- 
quired executive functions 
in a single module, called 
the nucleus. Other modules in the package tailor the 
executive system to its application 
by adding higher- 
level OS functions such as disk-file systems. The task 
programs and optional modules connect to the nucleus 
with simple software 
interfaces. 
Users can also add 
their 
own extensions. 
Since the nucleus is essentially 
open-ended, it can 
serve as the software foundation 
for expanding both 
the operating 
system 
and the variety 
of task pro- 
grams. Although most single-board computer applica- 
tions 
are 
dedicated, 
many 
do require 
higher-level 
capabilities. 


The OEM way 


The modular 
approach 
to system 
software 
fits in 
with the way most OEMs (and high-volume end users) 
apply single-board 
computers. 
They generally 
start 
with a minimum 
amount 
of hardware 
(often, just a 


Joseph Harakal, Software Product Manager. Intel Corp.. 
5200 Elam Young Pkwy.. Hillsboro. OR 97123. 


1. In a real-time multitasking system, task modules (A 
through E)can often perform their functions only after 
hardware-generated interrupts are serviced (highlighted). 
The executive in such a system provides intertask 
communications and synchronization. 


RMX/80 VIRMX,I86 featlns 


RM~~ 
IRM~M 


Nuclei 
Nuclei 


For iSBC 80/10 


For iSBC 80/20 


For iSBC 80/30 


Optional modules 


Disk-file system 


Disk 110 


Terminal handlen 


Free space manager 


Analog I/O handlers 


Bootstrap loader 


Debuggers 


Support packages 


Fortran-80 run-time 


Basic-80 interpreter 


8080/8085 fundamental 
support 


Free-space ma(lager 


Exceptiona!-<;onditions 
handler 


Optional modules 


I/O system 


Hierarchical file system 


Numbered file system 


Internal file system 


Physical file system 


Interfaces for custom 
files and I/O 


Human interface system 


Command-line decoder 


single board) to begin an application at lowcost. Then, 
when users are satisfied with the original functions 
and are willing to buy more, the OEM adds the 
executive options, tasks and hardware-with 
as fast 
a turnaround 
as possible. 


The problem with conventional "general-purpose" 
software 
systems 
is that 
they usually depend on 


hardware 
that the application may not need-for 
example, standard peripherals whereas a typical OEM 
system uses special peripherals. 
Modular OSs are 
designed to accommodate both. 
What's more, a conventional system can make it 
difficult and/or awkward to use new peripherals or new 
technology, such as magnetic-bubble memory-most 
command-line 
decoders, for instance, are not ac- 
cessible to the user. So, a user may discover that there 
is no straightforward 
way of adding new facilities. 


Call it foundation 
software 


For an even closer fit with single-board computer 
applications, the RMX/86 modules closely parallel 
hardware modularity: Each computer board contains 
program and data memory, serial and parallel I/O, 
and other generally required functions in addition to 
the CPU. Each user's system is expandable with 
optional modules. Frequently used devices like disk 
controllers and analog I/O are available. In addition, 
the user can connect custom devices to his system via 
the Multibus architecture. 


Corresponding to the hardware, systems software 
manages CPU, memory and I/O resources. Linked to 
optional modules, it can support standard 
iSBC de- 
vices like consoles and disk controllers. Similarly, 
users may add device-driver software modules for 
their custom peripherals. All software can reside in 
EPROM/ROM if mass storage is not available; other- 
wise, most of the system can be disk-resident. The 
disk-file module is suitable for such applications as 
data logging. 


The RMX/86 is designed for configuration on an 


Intellec development system according to user re- 
quirements. The same system supports task-module 
development as well as linking and locating in both 
high-level and assembly languages. It also provides 
libraries 
of frequently 
used program 
functions to 


minimize the amount of code the system designer 
must write and debug. 
To see how the RMX/86 works, consider a typical 


example. Sayan OEM develops a factory heating and 
air-conditioning control system having a single-board 
computer, analog I/O, special control devices and an 
operator terminal. He uses the nucleus, analog-han- 
dler and terminal-handler 
modules, plus user tasks 


stored in EPROM. 
But suppose the OEM's customer wants to enhance 


the system with, say, disk storage. He simply adds 
a disk controller board and uses I/O system software. 
The original programs could also be made disk-resi- 
dent. If the original application had been based on a 


2. The RMlC/86operating system treats all I/Oas flles- 
a feature that makes Iteasy to add new peripherals and 
special flies. 


3. Ahierarchical file system eliminates the need for 
scanning all the flies on a disk. IfSmith Isworking on 
Project A,he only has to choose between the flies related 
to his project. 


conventional 
executive, 
extensive 
redevelopment 
would have been necessary. 
If, on the other hand, the application had used the 
full I/O system from the start, initial sales would have 
suffered because the OEM's system would have been 
more costly. And if the software is not extensible, 
future sales opportunities are lost. 


A real-time multitasking executive gives a program 


the means to monitor and control external events. 
Tasks run concurrently, using communications and 
synchronization 
services of the. executive (Fig. 1). 


Events are signaled with interrupts, and the executive 
schedules resources 
on the basis of priority-for 


example, a task trying to bring a factory under control 
should have a very high priority. The executive decides 
whether 
a running task should be interrupted 
to 


process data from an interrupting 
device. 


The 
RMX/86 
nucleus makes such event-driven 


priority 
scheduling happen through resource man- 
agement. It monitors system states, determines task 
requirements, 
allocates resources and gathers them 
for reallocation. Resources include CPU time, memory 
and I/O. 
As in other systems, the highest-priority task that's 
ready to run uses the CPU; others are put on a read 
list. Finishing the high interrupt, the nucleus returns 
the CPU to the highest-priority 
ready task. 


Managing inner space 


A free-space manager, built into the nucleus, han- 
dles the 8086's megabyte addressing range, making 
sure that memory is used efficiently. The manager 
organizes memory into a tree-structured hierarchy of 
pools according to job requirements, 
and returns 
memory to pools. When the nucleus requires memory 
for a job, mailboxes or other functions, the manager 


provides it. Or, when a task requests memory-for 
example, to input data-the 
manager allocates it. This 


is done in segments that are multiples of 16 bytes, 
corresponding to the 8086's segmented memory. 


Tasks send data to each other through mailboxes 


which contain messages located in RAM. As in other 
systems, separate mailboxes are used for receiving 
and for responding. 


In the RMX/86, however, mailboxes provide several 


options, including'synchronization, 
mutual exclusion 


(which prevents one task from destroying another 
task's data) and communications-for 
example, with 


the outside world-through 
modules such as the 


terminal 
handler. 


The RMX/86 nucleus also provides other means for 
communications. One example is semaphores-low- 
overhead mechanisms for synchronization operations, 
resource allocation and mutual exclusion that require 
a simple flag. For example, one task can simply set 
a flag to tell another task that an event has happened 
("Analog data received"). 


All these functions are accessible with simple calls 


to the nucleus. For example, just two calls are needed 
to use the free-space manager: CREATE-SEGMENT 
to 


request memory and DELETE-SEGMENT 
to relinquish 


memory. Likewise, to obtain an mailbox, the task 
simply names the mailbol\ desired. The programmer 
doesn't need to know the internal structure 
of the 


executive, since the functions are accessible through 
easily programmed interfaces. 


Errors, big and small 


Another RMX/86 feature, the exceptional-condition 


handling, makes error handling selective rather than 
all or nothing. Programs can be designed to manage 
error conditions and take corrective action. 


Multitasking design is coming to the fore, especially 


for single-board-!,C applications that usually require 
a lot more software than previous !,Cs-an 
advance 


from 
simple 
foreground-background 
programs 
to 


techniques 
based on event priorities. 


Although 
single-board 
!'Cs started 
out 
in the 


mid-1970s at the low end of the OEM performance 
range, they have now reached the top in performance 
and memory capacity. As more and more OEMs and 
users take advantage of that increased capability, the 
size of applications 
programs grows-and 
grows. 


In the same period, the costs for developing software, 


salaries and overhead have almost doubled. Moreover, 
skilled 
programmers 
have 
become 
one 
of 
the 


industry's 
most limited resources. No wonder that 


software costs comprise up to 80% of system develop- 
ment costs today, and that the emphasis has shifted 
from in-house software design to buying off-the-shelf 
programs. 
Because multitasking 
designs have to be highly 
modular, 
time-saving 
tools such as high-level lan- 


guages, program libraries' and off-the-shelf 30ftware 
can be used freely to help keep development, main- 
tenance 
and expansion 
costs under 
control. 
Code 


written 
in high-level languages is a bargain today, 


compared 
to code written 
in assembly 
language: 


around $2.50 a byte vs $10 for assembly language. 
High-level code is not as compact, but it's far more 
cost-effective for the 80% of the tasks that run only 
about 20% ,of the time in typical applications. 
Today, there's a growing choice of languages. Struc- 


tured languages like PL/M and Pascal fit well into 
the "top-dawn" 
modular 
design technique 
used to 


divide an application into tasks. Others, like Fortran 
for mathematical 
applications and Basic for easy end- 
user programming. 
are also available. 
In general, a real-time multitasking executive offers 


a reasonable 
choice for the user who has a lot of 


software to write, must meet special requirements, 
and has no time to develop a custom operating system. 
The RMX/86 
system, with its modular design, fills 


the bill to save development cost. 


First, there's an option to specify to the nucleus 


whether or not there should be any error handling 
for a particular task. A programmer can write his own 
handler either to abort a task or to program a specific 
course of action-for 
example, report 
exceptional 
conditions and continue with next instruction; load 
copy of module and try again; start alarm program. 


The exceptional-conditions support also detects pro- 


gramming errors such as a wrong call to the nucleus 
and system problems like insufficient memory. Natu- 
rally, the RMX/S6 provides all normal OS functions. 
System options include a terminal handler for CRT 
and TTY consoles device drivers for Intel's floppy and 
hard-disk controllers and an integrated I/O system 
A subsystem of the I/O system supports tree-struc- 
tured directories hierarchical named files (Fig. 2). 


I/O features 
are vital 


Most single-board computers are used with special 
peripheral devices, and many with other kinds of files 
and media. So, the I/O system is designed to make 
it easier to add special files, new peripherals 
and 
custom device drivers-the 
user need never feel locked 


in. 


The RMX/S6 I/O system provides the user with a 


very general file concept-as 
a data sink or source. 


The characteristics 
of a specific storage 
medium 
dictate the access techniques for a given file. For 
example, a disk file may be accessed either in sequen- 
tial or random fashion, while a file accessed over a 
serial link (USART) must be processed serially. 
Using the data sink/source concept, the user can 
develop application programs without worrying about 
the physical device where the data will be stored. Such 
device independence simplifies application program- 
ming, and existing programs can be used with many 
devices. 
The RMX/S6 I/O system supports three types of 
files. 
Physical files represent the lowest interface level to 
retain device-independent characteristics. 
They pro- 


vide a simple, consistent interface to all devicedrivers. 
OPEN, CLOSE, READ, WRITE, SEEK and special instruc- 
tions perform all desired I/O operations. 


Streamfiles 
provide a temporary data-transmission 
path between tasks. One task may write data to the 
stream file while another reads them. The I/O system 
performs the required synchronization and buffering. 
Stream files offer the user a simple mechanism for 
passing data between tasks-one 
that remains consis- 
tent with other file options. The user can simulate an 
external device while waiting for hardware to be built. 


Named files 
are used for the conventional data 
storage on mass-storage devices like floppy or hard 


call 
rqendSlnltStask; 
CALL 
II"II; 
do 
forever; 


msg$token=rqrecelveSmessaQe(r~11tO~$X, 
OFFFFN,~reSp$ex,~exsval): 
call 
rqSsendSmessage(rqSnorma)$th$out, 
msqSto~en,out.resp,~exSval): 
msgStoken= 
rqsrec~lveSmessaqe(cutSresr 
,OFfF~H,~resPSex,@eXSVRI): 
call 
roSdeleteSsegrnent(~sg$tOken,~ex$v 


end: 
/. ot 00 forever 
*1 
eno: 


4. RMX/86can easily be expanded with user-coded taski. 
The one shown here Initializes a user program by calling 
the procedure 
IN IT and helps display messages. 


RQRECEIVE$MESSAGE Is a system primitive that examines the 
mailbox to be serviced and places the token for the first 


message there (MSG$TOKEN). Another system primitive, 


RQ$SENDMESSAGE, puts the token for the message Into the 
terminal handler's output mailbox. The primitive 


RQ$DELETE$SEGMENT clears the used memory and returns 
Itto the free-memory 
manager. 


disks for later access by another system. However, 
the RMX/86 goes one step farther 
by setting up a 
hierarchical directory of files. This feature lets the 
user organize his files to be consistent 
with his 
application (Fig. 3). 
The named-file system has another advantage: It 
permits 
file-access checking, so a user can decide 
which of his files he wants to protect and which to 
share with other users. 


Each of the file options can be configured independ- 
ently; the user may select the features he needs- 
neither more nor less. Furthermore, the user can add 
his own device drivers to the I/O system. 
The RMX/86 is designed to offer the user a wide 
spectrum of convenient functions (Fig 4).For example, 
the user of mass-storage systems has a display direc- 
tory and copy files available. Or, the OEM who needs 
his own interactive capability can easily extend the 
system's human interface routines to meet his require- 
ments. 


As I'P applications expand, so does the need for 
loaders that allow parts of the applications software 
to reside on disks. The RMX/86 package provides a 
resident system loader that permits loading for either 
absolute or relocatable format. •• 
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Faster and smaller than its predecessor, the iRMX 88 real-time 
modular operating system eases the transition from 8-bit to 16-bit 
IlCS, while supporting the 8087 arithmetic chip and other peripherals. 


Multitasking executive 
speeds 16·bit micros 


Even while it eases the transition 
from an 8-bit 
to a 16-bit world, a new operating system (OS) brings 
thoroughbred 
performance 
to the stable of modular 


systems 
software. 
The iRMX 88 multitasking 
ex- 
ecutive cuts both interrupt 
latency (the delay until 
a random 
event 
gets 
a response) 
and 
context- 
switching time (the interval during which the proces- 
sor changes from one task to another). 
Its nucleus 
is, therefore, 
faster-and 
smaller-than 
those of 
preceding 
operating 
systems. 
The 
iRMX 88 Executive 
provides 
fundamental 
multimasking 
software 
and complements 
the full- 
featured, 
multiprogramming 
iRMX 86 as (ELEC- 


TRONICDESIGN, March 15, 1980, p. 245). Through 
priority-based 
task 
scheduling, 
it 
concurrently 


monitors 
and controls 
multiple 
events. It provides 
real-time 
clock control, 
manages 
interrupts, 
and 
dispatches 
tasks. As an upgraded 
version of the 8- 
bit iRMX 80 Executive, iRMX 88 employs the same 
concepts and most of the same modules. Thus, the 
new as offers field-proven 
and reliable interfaces. 


Te.k•• her. r•• ourc•• 


The Executive will run with iAPX 88 or iAPX 86- 
based boards and supports Intel's iSBC 86/12A, iSBC 
88/40, and iSBC 86/05 single-board computera. Since 
it is fully configurable-not 
only procedure-by-pro- 
cedure, 
but 
also for all hardware 
addresses 
and 
interrupt 
levels-it 
also can be used with custom- 
designed boards that contain an iAPX 86 or iAPX 88 
processor, 
an 8259A programmable-interrupt 
con- 
troller, 
and 8253 programmable-interval 
timer, 
an 
optional 
8251A programmable-communications 
in- 
terface, 
and-perhaps 
most 
important-an 
8087 
numeric-data 
processor. 


In a multitasking 
system like the iRMX 88, several 


Je•• 
M. Irwin, Project Leader 
Intel Corp. 
5200 N.E. Elam Yo'Ung Pkwy. Hillsboro, OR 97213 


tasks execute concurrently. 
A task is an independent 
program 
that 
shares 
system 
resources 
and com- 
municates 
with other tasks. Each task has its own 
stack, where the registers used by the task are saved 
to shorten 
context-switching 
time. 


A 
task 
communicates 
with 
other 
tasks 
via 
messages, 
which convey data and synchronization 
information. 
These messages are channeled through 
data structures 
called exchanges. A task can send 
messages 
to an exchange 
(using the RQSENDpro- 
cedure) or wait for messages at an exchange (using 
the RQWAITprocedure). 
In the latter case, the task 
does not execute until a message is available or until 
a certain 
length 
of time has elapsed, specified in 
terms of "system time units" (minimum 
interval of 
real time recognized by the system). A task that is 
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1: Task stans running because it IScurrently 
the ready task WIth the highest prionty 


2 
Task 1$still ready but stops runnmg because it has no longer the hrghest priOrity 


3' 
Task 
waltS 
for 
a message 


" 
Task 
receives 
a message 
or completes 
a delay 
5' 
Task 
IS suspended 
6 
Task's resumed 


7' Runmng task suspends itsetl 


1. Tuka 
In thelRMX 88 Executive occupy one ollour 
atetea. 


Tranaillona .regoverned 
by the aeven occurrenceellated 
at 
the bottom 01thellgure. 


not willing to wait may accept any message from 
an exchange (using the RQACPT procedure) 
if one is 


available; 
otherwise, 
the task 
remains 
without 
a 


message. 
Each task exists in one of four states: running, 


ready, 
waiting, 
and suspended 
(Fig. 1). A task is 


running if the processor is executing instructions 
on 


its behalf. It is considered ready if it is either running 
or able to run. A task is waiting if it has requested 
a message but has not received it. Finally, a task 
is suspended 
if some other 
task 
has specifically 


requested 
that 
it not be permitted 
to run. 
Each task has a permanent 
priority, 
which in- 


dicates its importance 
relative to other tasks in the 


system and to interrupts 
from peripherals. 
Priorities 


range from 0 to 255, with 0 being the highest priority. 
The "idle task" executes at priority 255 and prevents 
any other task at that priority 
from running. 
The 


ready task with the highest priority 
is the running 


task. 
The software 
priorities 
correspond 
to eight 


hardware 
interrupts 
(Fig. 2). When the running task 


has a high priority, interrupt 
levels associated with 


equal or lesser priorities 
are masked off. 


Interrupts provide real-time access 


An interrupt 
invokes an interrupt-service 
routine, 
which either requests 
an end of interrupt 
(using the 


Hardware 
Software 


Level 0 
Highest 
1 
priority 
Level 0 


16 
17 
1 


32 
33 
2 


48 
49 
3 


64 
65 
4 


80 
81 


5 


96 
97 
6 


112 
113 
7 


128 
129 


Lowest 
255 
priority 


2. Of 256lnterruptlevels, 
the top 129 are essoclated with 


herdware. The remainder can be sssigned to software tasks. 


RQENDI procedure) or requests that a message be sent 
(using 
the RQISND 
procedure) 
to an interrupt 
ex- 


change associated 
with the active interrupt's 
level 
(Fig. 2). In the latter case, an interrupt 
task waiting 


anhe 
interrupt 
exchange would complete the inter- 


rupt servicing. The system can enable interrupts 
(via 


the RQELVL 
procedure) 
and disable 
them (via the 


RQDLVL procedure) and can set the interrupt 
vector 


associated 
with 
a given priority 
level (using 
the 


RQSETV 
procedure). 
The iRMX 88 treats interrupts 
as messages. When 


an interrupt 
occurs, the Executive creates a special 


message and sends it to the exchange associated with 
that 
particular 
interrupt. 
Should a previous inter- 


rupt message be at the exchange when the interrupt 
occurs, the message is changed to indicate' a missed 
interrupt. 
Any task awaiting the interrupt 
exchange 


receives the interrupt 
message 
and is readied 
for 


execution. If the task has a priority 
corresponding 


to the interrupt 
level, it will become the running task. 


The 
task 
that 
was 
running 
when 
the 
interrupt 


occurred 
is still ready to run, but is pre-empted. 


When the running task relinquishes 
control by wait- 


ing at an exchange (possibly for another 
interrupt), 


suspending 
itself 
(via the 
RQSUSP 
procedure), 
or 


deleting 
itself 
(via 
the 
RQDTSK 
procedure), 
the 


iRMX 88 dispatches 
the next ready task. 


Interrupt-processing 
tasks are simply tasks that 
wait at interrupt 
exchanges. They do not need to save 


the interrupted 
task's state or control the interrupt 


hardware. 
A task 
may simulate 
an interrupt 
by 
sending a message to an interrupt 
exchange (using 
the RQSEND 
procedure). 


Because 
the 
iRMX 88 imposes 
some software 


overhead, a direct interrupt-servicing 
facility is pro- 


vided for those cases where interrupt 
response time 


is critical. The interrupt 
vector is set with a pointer 


to an interrupt-service 
routine 
(using the RQSETV 


procedure); then all interrupts 
occurring at that level 


are handled by the interrupt-service 
routine, which 


is also responsible for all interrupt-logic 
control and 


state-saving. 
To complete the interrupt, 
the routine 


must use the RQISND or RQENDI procedure. 


Creating tasks and exchanges 


The iRMX 88' supports 
the dynamic 
creation 
of 
tasks and exchanges, as well as their deletion when 
they are no longer needed. Creating a task (with the 
RQCfSK 
procedure) 
places 
the 
new 
task 
on the 


system's list of ready tasks, according to its priority. 
The creation 
of an exchange 
(using 
the 
RQCXCH 


procedure) results in the initialization 
of an "empty" 


exchange-one 
that 
has 
no waiting 
messages 
or 


tasks. The deletion of a task (via the RQDTSK pro- 
cedure) results in its removal from all system lists. 
The deletion 
of an exchange 
(using 
the 
RQDXCH 


procedure) 
is only possible if no messages or tasks 


are waiting 
at the exchange. 


Suspension of a task (using the RQSUSP procedure) 
places the task on a list of suspended 
tasks 
and 


removes 
it from the list of ready tasks; to return 


the task to the ready state, 
the RQRESM procedure 


must be used. 


A coproce •• or tor number crunching 


Unlike previous operating 
systems, 
the iRMX-88 


can support the 8087 numeric-data 
processor (NDP) 
in a way that is invisible to the user. When an NDP 
task is created, the iRMX 88 initializes and maintains 
the state 
of the 8087 in a save area. 
Should an 
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unmasked 
error occur in the 8087, an interrupt 
is 


generated on a configurable 
level. Using the default 


interrupt-service 
routine, 
the iRMX 88 sends 
an 
interrupt 
message 
to the interrupt 
exchange; 
the 


user can then supply his own error handler. The error 
task must specify itself as a non-NDP task or the 
system will deadlock. But the error interrupt, 
if used, 


must not be masked off. 


The Executive includes "a terminal 
handler which 
establishes 
real-time 
asynchronous 
serial 
com- 


munication 
between an operator's 
terminal 
and the 
tasks 
running 
under 
the 
executive 
(Fig. 3). The 


terminal 
handler 
provides 
a simple 
operator 
in- 
terface, 
which includes line-editing 
features, 
a 64- 


byte type-ahead 
buffer, and control over the output. 


Since all port addresses 
and interrupt 
levels for 


the terminal 
handler 
are configurable, 
it supports 
any 
component 
configuration 
using 
an 
8251A 


programmable-communications 
interface 
with 
an 


8253 programmable-interval 
timer 
for 
baud-rate 
generation. 
A task 
interfaces 
with 
the terminal 


handler through two exchanges, where messages are 
sent to initiate 
read and write requests; 
they are 


processed on a FIFO basis. Characters 
are read and 
written 
in response 
to interrupts 
from 
the 8251 


programmable-eommunications 
interface. 
Each re- 
quest results 
in the transmission 
of one line to or 


from the terminal. 
Read requests 
are sent to the 


RQINPX exchange, and write requests 
to the RQOUTX 


exchange. 
When a request 
has been serviced, 
its 


message is sent to the specified response exchange. 


The iRMX 88 also contains a free-space manager, 


which maintains 
a pool of free RAM memory (Fig. 
4). Tasks request 
blocks of memory from the pool 


and return 
blocks to the pool. The request 
is made 


by sending a message to the manager's 
allocation 


exchange, 
RQFSAX, 
specifying 
the 
length 
of the 


needed block. If sufficient 
contiguous 
free RAM is 


available, 
the requesting 
task receives a message 


acknowledging 
the request 
and supplying 
the ad- 


dress of the block in the form of a message. Other- 
wise, the requesting task receives a message indicat- 
ing how much 
free 
RAM can be allocated. 
The 


requesting 
task may then ask for a smaller block. 


In either 
case, the response 
from 
the free-space 


manager 
is returned 
in the same message that was 


used for the request. If the task must have the block 
of memory, it makes an unconditional 
request; the 


Stttle 
('dhphy 
alqortt",,') 
dholay: 
00; 
$lnclude< :fl: led. lit) 
'include( 
:fl: rQlsna.ext) 
Sinclude( 
:f1 :rqend1.ell,t) 
Slnclude\ 
:fl :rqwatt.ext) 
Stnclude(:11 
:rqsetv.ext) 
'include( :fl:rqelvl.ext) 


DECLAREdisphySled 
'ntSexch."9tSd~crlotor 
PffB~IC; 


1''' display 
interrupt 
service 
routine 
*f 
displaySisr: 
PROC£()IJREINTERRIJPT 
63. 


1* check for proper interrupt */ 
OUTPUT 
(rql8ZS9.) 
-00.; 
(F NOT(O.PUT(rqS8ZS9.) 
,,"0 !lOft) - 0) no 
00; 
1* outPUt next 
character 
11' 


OUTPUT(rq$thS8251) 
c output$buffer( 
outputS index); 
outputSlndeJt 
•• outoutSlndex 
+ 
1; 
outputScount 
.. 
outoutScount 
- 
1; 
IF 
outPUUcount 
•• a THEN 
CAll 
rqSlsn<l{ 
.d1sp 
l.yStXChange); 
ELSE 
CAll 
rqSendl 
( . disp 
laySellchange); 
ENO displayS;sr; 


display: 
PROCEOIjRf; 
OECLAAE ~Slgeh<tctress 
ADDRESS; 
~ 
r-q$seh( .d1sPla)'Shr 
.displaySleovel); 
00 
FOREVER; 


/* 
coPy 
monitor 
and 
control 
information 
into 
the 
disolay 
buffer 
with 
tne 
template 
of 
the 
display 
*/ 


outputSin<te .•.• 
I. 
outoutScount 
• lENGTH(outoutSbuffer); 


/* 
enable 
the 
display 
interrupt 
and 
wait 
until 
the 


buffer 
has 
been 
output 
*/ 
CALL rqSelvl 
(.d1splay$ied): 
~ssa9eSaddress 
'" rqlwa 
it( .d1 SP 1aylied 
,0) 
; 
END display; 


8. The PROCEDURE 
DISPLAv(botlomhall) Illustrates how the 
IRMX 88 operating systam deals with random events. Hare, 
Intarrupt level 83 has been chosan by the usar. 


free-space 
manager 
then 
lets the requesting 
task 
wait until sufficient 
memory is available. 
When a 


block of RAM is no longer needed, it may be sent 
to the reclamation 
exchange (RQFSRX) where it is 


merged 
into the free-space 
pool. 


The building-block approach 


The iRMX 88 Executive is completely configurable. 


The minimum 
"nucleus" 
consists 
of the following 


procedures: 
RQSTRT 
(initialization), 
RQCTSK 
(task- 


creation), 
RQCXCH (exchange-creation), 
RQSEND, and 


RQWAIT. Any of the remaining 
procedures are auto- 


matically included when they are referenced. 
Inter- 


rupt 
support 
and the system 
clock are separately 


configurable. The port addresses used for the 8259A 
programmable-interrupt 
controller, 
the 8251A pro- 


grammable-communications 
interface, 
and the as- 


sociated 8253 programmable-interval 
timer are con- 


figurable 
to any iAPX 86 or iAPX 88 port address. 


The transmission 
rate 
of the terminal 
handler 
is 


configurable 
from 150 to 19,200 baud. The interrupt 


levels for the system-clock 
and terminal-handler 


interrupts 
are configurable to any level of the 8259A 


programmable-interrupt 
controller. 
Any 
unused 


level is configured 
to its default 
interrupt-service 


routines. 
The base of the interrupt 
vector used by 


the 8259A programmable-interrupt 
controller can be 
selected from interrupt 
levels 8 to 248. The smallest 


system 
time unit is 1 ms. 
An "interactive 
configuration 
utility" 
(ICU 88) 


simplifies 
the configuration 
process. 
This utility, 


which executes 
on the Intellec 
microcomputer-de- 


velopment 
system, 
asks the user a series of ques- 


tions, allowing him to specify his own board con- 
figuration or to use a default that corresponds to the 
iSBC 86/12A, 
iSBC 86/05, or iSBC 88/40 boards. 


To transfer 
an application 
from the iRMX 80 to 


the iRMX 88 Executive, 
the user must change the 


parameter 
for the create-task 
(RQCTSK) procedure 


from a 16-bit address to a 32-bit pointer. The descrip- 
tion of the task can then be placed in random-access 
or read-only memory. In the iRMX 88, the definition 
of task has been expanded to incorporate 
a flag that 


indicates 
whether 
or not the 8087 numeric-data 


processor will be used. If that flag is set, an additional 
94 bytes must be reserved for the task. Furthermore, 
the first parameter 
of the set-vector 
(RQSETV) pro- 


cedure must 
be changed to a 32-bit pointer. 


A robot demonstrates Implementation 


The iRMX 88 Executive demonstrates 
its value in 


a typical application: controlling an industrial robot's 
arm. 
The position 
of the arm 
in each of three 
dimensions 
is measured 
by an analog voltage on 


three input lines. The speed and direction of move- 
ment in each dimension is controlled with an analog 


00 FOREVER; 


DOCASEfIeld 
+ 1; 


/* next 
x Dosition 
*/ 


00' 
/* 
convert 
the 
character 
string 
ln 
the 
input 
buffer 
into 
a rea 1 nulllber */ 


7. An endless 
loop Is a typical 
method for capturing 
Input. 


The skeleton 
code for PROCEDURE 
INPUTshowsthelnterface 
with 


the executive 
via a CAll to an OS procedure. 


$title 
('monitor 
algortthfft') 
monitor: 
00; 
1ft *>tIttor 
x taSk */ 
tIOnttorSx: 
PROCEOlJRE; 
DECLARE.essageSaddress 
AOORESS; 


CAlL rq$cKch{.wattinqhd); 
00 
FOllEV£R' 


l'Ilesslqehddress 
s rq$acpt( 
.wai t ingSed}; 
dcontrolSinput· 
SHR{ INPUT(adC$low). 
4) .• 
SHl( 
INPUTI .0<$1I1gll). 
'); 


K$mon1torSposition 
•• dcontrol$input 
ft dtnouthcale; 


drate'"' 
( dposltion 
- dfllOnitor$positton 
) •. 10; 


doos1tion-" 
X$monltor$pofition; 
- 
--- 
- -~ 
.._.._--- 


CALLrq$send(. 
Klact tonSed •• x$pos it tonSmessage); 


ENO; 
ENDfllOnltor$x; 


8. 
PROCEDURE 
MDNITDRSxlsa task that hastD run every 16 ms. 


The IRMX 88 procedure 
RowAITacceptstha 
dealrad time delay 


as an argumant. 


Stitle 
('control 
algorithm') 
control: 
00; 
/* contro 1 x task 
.•./ 


controlSx-: 
PROCEDURE; 
DECLARE-ess4gehddress 
ADDRESS; 


00 
FOREVER; 
messageSaddress 
= rQ\wa1t(. 
dact 
ionSed.D); 


dcontrolScurrent 
•• maddrate 
•. 


( nextSdposttl0n 
- dposltion 
) / A8S( next$x$position 
- 
lastSdpos 
it ton 
); 
xScontro lSoutput 
• SHL( FlX 
( 


dcontrolScurrent 
* dscale 
). 
4) .• KSoutputSselect; 


OUTPUT(dac$h'igh) •• HIGH(x$controlSoutput); 
OUTPUT(dacSlow) •• LDW(dcontrolSoutput); 


END; 
ENDcontrol$x; 


9. This control algorithm 
sends data to the robot arm's X- 


axis through 
a d-a converter. 
The task remains dormant 
until 


the INPUTprocedure 
from Fig. 7 makes It up. 


current 
on three output 
lines. 


The hardware consists of an iSBC 88/40 board with 


an iSBC 337 high-speed math multimodule, 
an iSBX 
328 analog-output 
multimodule, 
and a CRT terminal 
with an RS-232 serial interface. 
The position of the 
arm in any dimension is read from the a-d converter 
on the iSBC 88/40; the converter is multiplexed over 
the three analog inputs. The d-a converter 
on the 


iSBX 328 analog-output 
multimodule 
is multiplexed 
to control the current to three stepper motors, which 
in turn control the arm's motion. A display (Fig. 5) 
is maintained 
on the CRT terminal 
and gives the 
robot's current position in three dimensions, the rate 
of change in each direction, and updatable 
fields for 
the desired position, as well as the maximum 
rate 
of change in each direction. 


The display 
algorithm 
(Fig. 6) continuously 
up- 


dates the display from the control and monitor data 
bases. The monitor 
and control data bases update 


the display buffer. The display task initializes 
the 
display index and display count, enables the display 
interrupt, 
and waits 
at the display-interrupt 
ex- 
change. 
The display-interrupt 
service 
routine 
re- 
sponds to display interrupts 
by outputting 
the next 
character 
from the display 
buffer. 
When the last 
character 
in the display buffer has been output, 
a 


message is sent to the interrupt 
exchange; otherwise 
an end-of-interrupt 
is sent. 


The input algorithm (Fig. 7) accepts digits as they 


are typed on the CRT terminal 
and enters them into 


the control field being updated. 
The fields on the 


right-hand 
side of the display are updated, starting 
with the top field and progressing 
to the bottom. 


Entry of a carriage return 
causes the values in the 


updated 
field to update 
the control-data 
base; the 


input 
algorithm 
then 
proceeds 
to the next field. 


Backspace discards 
the last digit typed. All other 
characters 
are ignored, 
and the user cannot 
type 
outside the defined fields. The input-interrupt 
rou- 
tine receives a character 
with each interrupt 
and 
copies it into the display and input buffers. 


The monitor algorithm 
(Fig. 8) samples the posi- 
tion of the robot's arm 60times per second. It updates 
the monitor data base and then signals the control 
program 
through 
the appropriate 
exchange. 


The control algorithm 
(Fig. 9) waits at the proper 
exchanges 
for a message 
from 
the 
input 
or the 


monitor algorithms. It then outputs a control current 
to the d-a converter 
based on the relative 
position 
of the robot's arm.D 


Choosing a 
YLSI-e:OIIIpatible systeln 


VLSI offers expanded 
modularity for operating systems; 
the intended application 
will determine the most appropriate 
system 


By integrating 
more functions into silicon, very 
large-scale integrated (VLSI)circuitry lowers the cost of 
ILCSand improves their performance and ease of use. 
But the advent of VLSIraises a question: which ~c 
operating systems enable a user, especially an OEM,to 
take advantage most quickly of these hardware im- 
provements? This question can be answered by examin- 
ing the characteristics 
of available ~c-operating sys- 
tems in the light of VLSIadvances. 


An operating system's intended application is a key 


consideration in its selection. No operating system is 
ideal for every 
application and customer. 
For this 
reason, designers tend to optimize operating systems 
for specific types of applications. 


Microcomputer operating systems fall into two cate- 


gories: systems optimized for efficient development of 
new software and those optimized for efficient execu- 
tion 
of existing 
software 
(Fig. 
1). Development- 


oriented systems tend to sacrifice performance to ease 
of use, while execution-oriented 
systems make the 


opposite trade-off. It is tempting to characterize the 


two types 
of systems 
as either 
end-user-oriented 


(execution) systems or OEM(development) systems. 
But such a categorization is inadequate because many 
end us~rs are concerned with software development, 
and many OEMSare concerned with software execution. 


Development- versus execution-oriented 
In the 8-bit ~c world, CP/Mand Intel's ISIS(Intellec 


development 
system) 
operating 
systems 
are 
good 
examples of products targeted 
at efficient software 


development. In the fast-growing 16-bit ~c segment, 
ISIS (Series III) and the UNIXoperating system and 
derivatives, such as XENIX,fill the development need. 
Software 
developed 
with 
one 
of these 
operating 
systems is often executed on another machine running 
an execution-oriented 
operating 
system. 
As more 


development throughput is required, such as compila- 
tions 
per 
hour, 
users 
move from single-terminal, 
single-task systems (such as CP/M)to multiterminal 
systems (such as UNIXor MP/M)and to multiprocessor 
development systems (such as Intel's NDS-1). 


/// 
/ 
~-------------------------------- 


Increasing 
dev~lopment 


throughput 


(lines 
01 


debugged 


code 
per day) 


Increasing 


execution 
throughput 


(transactions 
permln., 


loop updates 


per sec.) 


Ellicienl 
development 
more 
important 


for the OEM 


Efficient 
executIon 


more 
important 


lor the end 
user 


An operating system's intended 
application 
is key in its selection. 


Most !LCsystems 
are execution-oriented 
and are 
often most critical for OEMSwho must stay competitive 
in price and performance. Rapid program development 
is usually secondary to efficient software execution. An 
OEMcan gain a significant competitive advantage by 
using an operating system that provides faster execu- 
tion times, less expensive investment, ease of use and 
the ability to be upgraded. 
~perating 
system 
vendors, 
including Intel, 
have 
deSigned a range of products for different needs. CP/M, 
for 
instance, 
is a 
logical candidate 
for 8-bit 
!LC 
applications, 
in which only single-task execution is 
required. 
For 16-bit applications, multiprogramming- 
type operating systems, such as MP/M,iRMX86 and 
iRMX 88, are more appropriate 
because they take 
advantage of the 16-bit processor's power. An OEMfor 
whom real-time execution is important might consider 
iRMX 86. If background 
program 
development 
is 
crucial, MP/Mmight be a better 
choice. For highest 
performance, 
users 
should consider multiprocessing 
operating systems, such as iRMxJMMX800. 


Other selection criteria 


Although the intended 
application is paramount, 
other 
considerations 
are important 
in selecting an 
operating 
system. 
The overriding 
factor in light of 
current trends is probably the ability of a system to 
keep pace with the impact of VLSIon !Lcperformance 
and cost. This consideration entails several selection 
criteria, 
including transferability, 
multiprocessing ar- 
chitecture, configurability and interfacing to modules. 


First, 
an 
operating 
system 
should 
be easy 
to 
transfer_t 
least in part-into 
VLSIsilicon. Putting an 


IEEE 
fI?aling 


point 


FIg. 2. Layered operating ey8tllme 
with standard 
interfaces. 
standard modules and configurability are key elements in designing 
I'C operating systems to take meximum advantaga of lowar cost, 
higher performance 
VLSI. 


operating system into EPROM,for example, can improve 
. speed find lower cost. Vendors should state 
which 


operating 
system 
functions will be integrated 
into 


silicon, and when. 


An operating 
system 
should provide support 
for 


multiprocessing, 
and VLSIhas made multiple-!Lc sys- 


tems practical. OEMSshould look for operating systems 
with multiprocessor 
architectures 
or other features 


that ease the move to multiprocessing. Such systems 
typically include fast context switching, task-to-task 
communication, synchronization and memory message 
passing 
features. 
For example, 
the 
new iMMX800 


Multibus message-exchange 
software 
allows 8- and 


16-bit, 
master-to-master 
and 
master-to-intelligent- 


slave single-board computers to multiprocess loosely on 
the Multibus multiprocessor bus. 
Modularity is another important criterion in select- 


ing an operating system. The iRMX86, for example, 
consists of layers of modules that can easily be moved 
into silicon as required (Fig. 2). This modular design 
has enabled Intel to develop a new component dubbed 
80130 Operating System Firmware 
(iOSF)that inte- 


grates a timer, an interrupt controller and the iRMx86 
kernel. 


An operating system should include standard inter- 


faces to modules. For example, iRMX86 uses a standard 
object-oriented format for interfaces to jobs, tasks and 
message primitives. At a higher layer, iRMX86 offers 
standard device-independent interfaces to drivers for 
the new 8089/8272-based Winchester- and floppy-disk 
controllers and other device controllers. The interface 
itself eventually will move into silicon. Only standard 
interfaces will allow this to occur. 
An operating system should also provide industry- 


standard 
interfaces to popular program-development 


languages, 
such 
as 
Intel's 
universal 
development 


interface (UDI)and universal run-time interface (URI). 
Intel's new uDIIuRI-compatible languages, 
FORTRAN 


86, Pascal 86, PLMl86and ASM86, can run on any 
uDIIuRI-compatible operating system. 


Operating systems should either support or should 


soon support the leading local-area networks, such as 
Ethernet, 
and global-area 
networks, 
such as X.25 


2780/3780. In November, iRMX86 will provide the first 
high-level 
support 
for Ethernet, 
the 
tri-corporate 


Digital Equipment Corp., Intel Corp. and Xerox Corp. 
local-area network standard. Prestigious firms commit- 
ting to Ethernet include Hewlett-Packard Co., Siemens 
Corp., Nixdorf Computer Corp., Olivetti Corp. and 
~ilog Corp. Intel will provide high-level, data-link-layer 
mterfaces to an Ethernet 
controller (iSBC550) on the 


standard Multibus, via the new Multibus interprocessor 
protocol (MIP). Ethernet 
will be supported in iRMS86 


via iMMx.These are all standard modules with standard 
interfaces. 
• 
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Microcomputer 
Operating 
System 
Trends 


advances in VLSI and other 
technologies Jorce the 
development 
of advanced 


operating systems 


As the use of IJ-CS expands, 
demand 
for high- 
I"l. /eve//anguages 
and human machine methods 
of interfacing 
will ewand 
in 1982 and beyond. One 
major 
component 
of the expanding 
demand 
con- 


cerns 
IJ-C operating systems. 


An 
operating 
sy~tem perfomls 
re",ource management 
and 


human-to-machine 
translating 
funet,ons. 
Technically. 
it 
i~ju~t another 
computer 
program 
a "tCri~\ 
of in...tnJctu.m~ 


that tell the machine 
•.•hat to do under a variet) 
of condition,. 


Major 
operating 
~y~tem 
funclIom, 
include 
management 
of 


memory. 
I/O peripherals. 
and the central proce"or. 


When 
compute" 
were fIN developed. 
the programs 
(or 


im.truction~) 
were entered 
into the machine each lime a parti- 


cular job wa, started. 
Onl) 
with the ability to 'tore 
a program 


in the computer's 
memory. 
over 30 ycan. ;Jgo. did the concept 


of computers 
as we know them tl!day truly emerge. 
The ability 


to 
store 
a program 
meant 
that 
a computer 
could 
pertorm 


repetitive 
tasb 
•.•hile the operator 
had only to enter 
intomla- 


tion upon ",hich 
calculations 
were pert·ormed. 


Once 
it became 
possible 
to ,tore programs. 
the development 
of operating 
~ystems began. 
Operating 
systems 
were stored in 


the computer, 
memory. 
and provided 
the u-er with a hank of 


stored 
computer 
instruction, 
that could be u,ed With a number 
of different 
application 
programs. 


Over 
the years. 
operating 
systems have evolved 
to the point 
where 
they 
have 
three 
main 
pUrp<"es. 
Fi"l. 
they 
provide 


clear. 
consistent. 
and ea~ily 
under.-.toc.xl guideline~ 
to u\er~ 


concemine. 
how 
the machine 
work\. 
A •..ub-objcctive 
i...•to 


provide 
a~ ea!'lier, more 
"friendly" 
human 
interface 
to the 


/-Lc. 
Second. 
they 
pertoml 
initiali/ation 
and 'tan-up 
func- 


tions 
"automatically" 
\0 that -to 
the u~er- 
the machin~ 
is 


ready 
to perform 
its baSIC functions. 
This initialization 
func- 


tion 
originally 
included 
only 
initial 
stan-up. 
but no" 
ot"ren 


includes 
methods 
to recover 
from erro" 
in both hardware 
and 


software. 
Third. 
they provide 
efllcient 
machme 
and 'torage 


resource 
management 
so that different 
user ....or programs 
can 


) 


Inc<easing 
Development 
Throughput 
(Lines Of 
Debugged 
Code/Day) 


Peter 
I. WolochoH" is 11'l1hthe OEM Microcomputer 
Systems 


Div. of/nrel Corp. Hillsboro. OR. 
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1: 


,RMX 


1 


/iMMX 
~~_.I·------- 


1/ 
I 
iRMX 86 


I1-< 
MP/M 
I 
iRMX 88 


Increasing 
Execution 


Throughput 
(Transactions, 
Operations 
Loop 
Updates 


Per 
Second) 


share 
the same 
resources. 
(e.g .. memory. 
peripherals. 
I/O 
ports. 
a floating 
point program 
or the processor 
itself). 
Although 
virtually 
all J.l.Coperating 
systems 
provide 
users 
with 
methods 
to accomplish 
these three main purposes. 
cer- 


tain 
operating 
systems 
- 
designed 
for specific 
types 
of 


applications 
- 
have 
gone 
far beyond 
the three 
cornman 


objectives. 
One 
method 
of viewing 
J.l.C operating 
systems 
has to do 
with 
the primary 
purpose 
to which 
the J.l.C is directed. 
Two 
major 
distinctions 
exist. 
On one hand. 
some 
J.l.C operating 
systems 
are used primarily 
to develop 
new software 
systems. 
In this case. 
the operating 
system often includes 
only features 
and routines 
that are useful to persons 
writing 
and compiling 
software 
programs. 
On the other hand. other J.l.Coperating 
systems 
are directed 


primarily 
at efficient 
execution 
of software 
programs 
for 


various 
applications. 
In this case. the operating 
system 
often 
includes 
routines 
and abilities 
targeted 
to fast. easy program 


execution. 


software 
development 
OS 


Within 
the current 
world of J.l.Coperating 
systems. 
examples 
of those 
oriented 
to efficient 
software 
development 
include 
such 
products 
as UNIX (developed 
by Bell Laboratories) 
and 


its 
related 
XENIX 
from 
MicroSoft. 
CP/M 
and 
CP/M-86 


from 
Digital 
Research. 
and ISIS and Networked 
Develope 
ment 
Systems 
from 
Intel. 
CP/M 
and 
ISIS-Series 
II are 
examples 
of operating 
systems 
designed 
for the technology 
and power 
of8 
bit J.l.Csystems. 
UNIX was designed 
to mateh 


the 
16 bit minicomputer. 
(e.g .. DEC 
PDP-Il) 
and now is 
being 
ported 
(e.g .. XEN1X) 
to the newer. 
more powerful 
16 


bit J.l.C systems. 


Development 
oriented 
software 
systems 
provide 
growin~ 


levels 
of 
programmer 
support. 
CP/M. 
for example. 
is a 


single 
user. 
single 
terminal 
system. 
UNIX provides 
suppon 


to multiple 
terminals. 
so more than one person can be devel- 
oping 
software 
at one time. 
Inters 
Networked 
Development 


System 
provides 
suppon 
for 
both 
multiple 
users 
over 
a 
network. 
and 
suppon 
for development 
on multiple 
proc- 
essors 
as well. 


execution 
oriented 
OS 


The 
second 
major 
category 
of operating 
systems 
comprises 


those 
primarily 
targeted 
to meet the needs of efficient 
execu- 
tion of application 
software 
already 
written. 
developed. 
and 


tested. 
This category 
includes 
the largest number of systems. 


and is often 
critical 
to effective 
utilization 
of J.l.CSin applica- 
tions 
such as industrial 
control. 
communications. 
transaction 
and word 
processing. 
interactive 
graphics. 
and simulation. 


Often. 
execution 
programs 
working 
in conjunction 
with 
execution-oriented 
operating 
systems 
arc 
developed 
on a 


mainframe 
'or 
minicomputer. 
with 
a cross-translator. 
The 
other 
alternative 
is to develop 
the software 
on a J.l.C using a 


development 
oriented 
operating 
system 
that has tailored 
its 


human 
interface 
more to the trained 
programmer 
than users 


of the end product. 
. 


In addition 
to the standard 
purposes 
of an operating 
system 


- 
simple 
human 
interfaces. 
initialization. 
and 
resource 
management 
- 
operating 
systems 
for efficient 
program 
execution 
have 
a number 
of other objectives 
as well. 
These 


include 
real-time 
operation. 
multiprogramming. 
multi- 


tasking. 
multiprocessing. 
and 
effective 
scheduling 
and 
priority 
determination. 


real.-time operation 


Many 
real-time 
operations 
are dedicated 
to specific 
applica- 


tions. 
such as controlling 
a machine 
or series of machines. 
As 
such. 
they 
often 
run the same 
software 
programs 
over 
and 
over 
again. 
depending 
on inputs 
received 
from 
monitoring 


and measuring 
devices 
attached 
to the machine 
they control. 


The 
primary 
characteristic 
of such applications 
is that the 


data or input that causes 
the J.l.Cto act is not regular. 
and does 


not occur 
at a panicular 
rate. As a result. 
the J.l.Cprogram 
and 
operating 
system 
must be able to handle 
inputs as they occur. 


and to monitor 
or control 
activities 
based on these real-time 


inputs. 


mUltiprogramming 


This 
refers 
to the ability 
of an operating 
system 
to suppon 
several 
independent 
applications 
executing 
concurrently. 
If a 


J.l.C. for example. 
is used to provide 
an integrated 
business 


office 
system. 
the software 
might be divided 
into a number 
of 
separate 
applications. 
One 
might 
focus on WP. 
another 
to 


manage 
the printer. 
and perhaps 
another 
to manage 
an inter- 
office 
electronic 
mail 
service. 
Each 
of these 
applications 


would 
involve 
a number 
of tasks devoted 
to different 
pans of 


the svstem. 
A~ operating 
system 
that suppons 
multiprogramming 
al- 


lows this division. 
and consequently 
makes it easier to devel- 
op the different 
applications 
separately. 
and insure that they 


do 
not 
interfere 
with 
each 
other. 
This 
is accomplished 
by 


estabLishing 
a separate 
environment 
for each 
application. 


These 
environments 
provide 
the basic appearance 
of a series 
of individual 
machines. 
while 
sharing 
the resources 
of only 


one. 
A 
multiprogramming 
operating 
sysleni 
must 
manage 


this di vision. 
keep track of the tasks and requirements 
of each 
application. 
and ensure 
that each 
task 
is given 
the correct 


priority. 


multitasking 


Multitasking 
refers 
to the ability 
of an operating 
system 
to 
effectively 
manage 
several 
tasks. 
of one computer 
program. 


that are operating simultaneously. Myltitasking 
is an im- 


portant 
sub-set 
of multiprogramming. 
wherein 
several 
pro- 


grams 
are 
concurrently 
being 
executed. 
Many 
applications 


require 
that one applications 
program 
involve 
different 
tasks. 


Often. 
these 
tasks 
must operate 
based 
on data developed 
in 


other 
tasks. 
and hence a form of task-to-task 
communication 


is required. 
Generally. 
operating 
systems 
designed 
for effici- 


ent 
progr-am 
execution 
require 
some form of "executive" 
to 


manage 
tasks. 
priorities. 
and intcrtask 
communication. 
As a 


result. 
common 
resources 
such as J.l.P memory 
and I/O de- 


intel 


vices can be shared by multiple 
tasks and can be kept as busy 


as possible. 
adding 10overall system efficiency. 


multiprocessing 


Multiprocessing 
refe" 
to the ability of an operating system to 


support 
multiple 
processors. 
In certain 
applications. 
the 
demands 
of the applications 
exceed the capacity of a single 
processor or iLC. As a result. more processors may be added. 
When 
this 
occurs. 
the role of the operating 
system 
IS to 
efficientlv 
allocate different 
processing requirements 
to the 


various 
processors. 
to keep track of ",hich 
jobs havc been 


sent where. 
and 10 assure that the total system resources are 
effectively 
utilized. 
Multiprocessing 
is becoming 
more at- 
tractive 
as a way to expand the functions 
of particular 
iLC 


applications 
without 
the need to entirely 
rewrite a program. 


As iLCs become less costly compared to software develop- 
ment 
and 
maintenance. 
many 
systems will 
use multiple 
processors. 
and operating 
systems will 
be required 
to effi- 
ciently 
manage multiprocessing 
configurations. 
A means for 
linkage 
of 
multiple 
processors 
and operating 
systems 
is 


Inte!"s 
iMMX 
800 (Multibus 
Message Exchange) software 


and iSBC 550 Erthemet 
communications 
controller. 
They 
support 
the needs of local area network applications 
such as 


office 
automation. 
distributed 
data processing. 
factory data 


collection. 
research data collection. 
intelligent 
tenninal 
and 
other EDP-relaled 
applications. 


scheduling 
and priority determination 


As iLC operating 
syslem~ are required to manage even more 
complex 
functions 
- 
such as multiple 
programs. 
multiple 


Processor Management: 
iRMX86 
UNIX 
CPIM 
RSX-IIM 
RT-ll 
MTOS·86 


SchedUling 
Realtime 
Multiprogram 
Batch 
Realtime 
Realtime 
Realtime 


Multitasking 
Yes (64K) 
No 
No 
YBS(64K) 
No 
YBs(4K) 


Priority Levels 
255 
None 
None 
250 
None 
255 


MUltiprogramming 
Yes (64K) 
Yes (64K) 
No 
Yes (64K) 
Foreground 
No 


IBackground 


Multiprocessor 
iMMX 
No 
No 
No 
No 
YBs(16) 


Multiuser 
Release5 
YBS 
No 
Yes (4) 
No 
No 


Interrupt Management 
Yes 
No 
No 
Yes 
YBS 
YBS 


Error Management 
4 levels 
Yes 
No 
Yes 
YBS 
No 


Powerfail Protect 
No 
No 
No 
Yes 
No 
No 


Memory Management: 
iRMX86 
UNIX 
CPIM 
RSX-IIM 
RT·11 
MT05-86 


Dynamic 
Yes (1MB) 
Yes (64K) 
No 
Optional 
No 
Yes (64K) 


II of Memory Pools 
64K 
One 
One 
8 
One 
32 


Memory Resident 
YBS 
No 
Yes 
Yes 
No 
Yes 


Application Loader 
Yes 
Yes 
Yes 
Yes (115: No) 
Yes (RT": No) 
No 


Bootstrap Loader 
Yes 
Yes 
No 
Yes 
Yes 
No 


(P) ROM'able 
Yes 
No 
No 
No 
No 
Yes 


Device Management: 
iRMX86 
UNtX 
CPIM 
RSX·IIM 
RT-ll 
MT05-86 


Concurrent 110 
Yes 
YBS 
No 
YBS 
Yes 
Yes 
110Buffering 
Yes 
Yes 
No 
Yes 
Yes 
No 


Reentrant 110 
Yes 
Yes 
No 
Yes 
Yes 
Yes 


Asynchronous 1/0 
Yes 
No 
No 
Yes 
Yes 
Yes 


Synchronous 1/0 
Yes 
Yes 
Yes 
Yes 
Yes 
N<>- 


Device Independent110 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


Max. II of Drivers 
64K 
256 
256 
16 
256 


Data Management: 
iRMX86 
UNIX 
CP/M 
RSX·IIM 
RT-ll 
MT05-86 


File Support: 
, 1. Sequential 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


2. Indexed Seq. 
No 
No 
YBS 
No 
No 


3. DirectAccess 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


Swapping 
No 
Yes 
No 
YBS 
No 
No 


Overlays 
Yes 
Yes 
Yes 
Yes 
Yes 
No 


Hierarchical 
Directories 
Yes 
Yes 
No 
No 
No 
No 


Stream Fiies 
Yes 
Yes 
No 
No 
No 
No 
Mailboxes 
Yes 
No 
MP/M 
No 
No 
No 


Criticai Regions 
Yes 
Yes 
No 
No 
No 
Yes 
Host System For Development 
Yes (With UDI) Yes 
Yes 
Yes (115: No) 
Yes (RT": No) 
No 


Figure 
3: Comparison 
of microcomputer 
operating 
systems 
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tasks. 
and multiple 
processors 
- 
the ability of the operating 


system 
to schedule 
activities 
becomes 
a primary 
considera- 
tion. 
In early 
multiprogramming 
operating 
systems. 
many of 
these 
scheduline 
routines 
were 
time 
drivcn. 
That 
is. one 
program 
would ~be allowed 
to execute 
for a ccrtain 
time. 
It 
would 
then 
be interrupted. 
and another 
program 
would 
be 
allowed 
to execute. 
This time drivcn 
scheduling. 
in effect. 
forced 
multiprogramming 
to occur. 
but also oftcn involved 
a 


significant 
amount 
of operating 
sy~tcm overhead 
to manage 
thc process. 
Subsequently. 
the approach 
of event 
driven 
scheduling 


was 
devcloped. 
With 
this approach. 
programs 
and tasks are 


allowed 
to proceed 
until 
some 
predetermined 
evcnt 
causcs 
the operating 
system 
to 'interrupt 
the running 
task and suh- 
stitutc 
another. 
In many·applications. 
event driven 
schedul- 


ing 
is the most 
efficient 
manner 
of allocating 
resources. 
In 


ad~dition. 
evcnt 
driven 
operating 
systems 
can 
often 
he 
modified 
to include 
some 
time driven 
scheduling 
routines. 


where 
the reverse 
is not possible. 
As a result. 
evcnt 
driven 


svstems 
are more 
fiexible 
and c~n manage 
the J-LC and othcr 
system 
resources 
more efficiently. 


future issues 


As 
the 
J-LC 
world 
continues 
to evolve 
rapidly. 
changes 
in 
scmiconductor 
technology 
will continue 
to force 
evolution 


and 
improvement 
in operating 
systems. 
As this evolution 
occurs. 
a number 
of trends and developments 
will infiuence 
the user's 
choice 
of appropriate 
opcrating 
systcms. 
Some of 
these 
developments 
include: 


Very 
Large 
Scale 
Integration 
(VLSI) 
Trends. 
As more 


complex 
functions 
arc 
integrated 
into 
J-LC chips.operating 
svstems 
will be required 
to support 
a broader 
variety of needs 
a~d application 
programs. 
The benefits 
of VLSI - 
such a, 
increasing 
density. 
substantial 
improvements 
in function. 


and 
rapidly 
declining 
costs 
per function 
- 
accrue 
to those 
who 
rapidly 
use the newest 
technologies. 
As a result. 
J-LC 
users 
on the leading 
edge often can build significant 
compet- 
itive advantages 
by being first to market. 


With 
regard 
[0 operating 
systems. 
trends 
toward 
greater 


VLSI 
integration 
imply 
that 
operating 
systems 
should 
he 


evaluated 
based 
on their ability 
to most rapidly 
use tcchnol- 
ogical 
advances. 
This 
ability 
to capitalize 
on VLSI 
trends 
includes: 


• 
Operating 
systems 
with the potential 
to be integrated 
into 


silicon. 
Intel. 
for example. 
has introduced 
a dcvice 
that 
intc!!rates timers. an interrupt 
controller. and multipro- 


gra~ming 
arid multitasking 
operating 
system 
"primitives" 


into 
one 
device. 
(These 
operating 
system 
functions 
arc 


cquivalent 
to those 
of the iRMX 
86 kema!.) 
In essence. 


some 
of the traditional 
software 
functions 
will become 
pan 


of the hardware. 
Such 
a development 
opens 
a number 
of 


vistas 
for future inte~!ration . 
• 
Operating 
systems 
';,rganized 
to take 
advantage 
or 
new 
trends 
in 
J-LC 
architecture. 
One 
of 
the 
mo\l 
promising 
developments 
in this area 
is ohject-orientcd 
architecture 


such as that implemented 
o'n iAPX 86 processors 
under the 
iRMX 
86 operating 
system and on Intel's new iAPX-432 
32 
bit micromainframe 
product 
family. 
Essentially. 
an ohject- 


oriented 
architectufC 
treats 
different 
kinds 
of 
data 
and 
instructions 
as ··objects" 
and provid~s 
common 
functions 


that can manipulate 
objects 
in a consi\tent 
manner. 
Morc- 


over. 
the object 
oriented 
architecture 
al\o 
meshe,-; closely 


with the new types of high level languages 
- 
,uch as Ada 


- 
now beinQ brouQht to market. 
These devclopments 
begin 
to provide 
;;Cs 
de~igned 
to optimize 
both program 
devel- 


opment 
and execution. 
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T 
he 
benefits 
of VLSI - 
such as 
increasing 
density, 
substantial 
improvements 
in function, 
and 
rapidly 
declining 
costs per function 
accrue to those who rapidly 
use the newest 
technologies. 


Standards 
for 
J-LC 
Languages. 
J-LC 
applications 
have 


evolved 
requiring 
higher 
level 
languages 
so Icss technical 
users 
can 
casily 
participate 
in VLSI 
technology. 
Without 
suhstantial 
advanced 
planning. 
thc use of highcr 
Icvcl 
lan- 


£!ua£!cs can cause siQnificant problems 
with operating: sy\tcms. 


Onc~ example 
of h'Ow advanced 
planning 
is donc 
is Intel's 


approach. 
Intel's 
iRMX 
86 operating 
systcm contains.both 
a 


Universal 
Development 
Interface 
(UD!) 
and 
a 
Umvep;al 
Runtime 
Interface 
(UR!). 
These 
two 
interfaces 
provide 
a 


standard 
upon which 
high level language, 
can he hoth devel- 


oped 
and run. 
In essence, 
the UDI/URI 
approach 
is develop- 


inQ a "software 
bus" 
or serics 
of standards 
for easy 
and 
co~nsistent 
language 
development. 
Without 
such an approach 
to standardization. 
each new language could he retarded 
in its 


development 
and each 
new proce",or 
could 
rcqulrc 
a l'Om- 


pletely 
new set of compilers. 


Arnone 
the many 
benefits 
of this approach 
are those 
of 
particulai= 
interest 
to persons 
who have been hesitant 
to use 


J-LCSbecause 
of the lack of standardized. 
high-level 
computer 
languages. 
With the development 
of the UDI/URI 
approach 
in iRMX 
86. for example. 
languages 
currently 
or soon tO,be 


available 
include 
FORTRAN 
86. PASCAL 
86, PLM/86 
and 
ASM 
86. 
Another 
major advantage 
of software 
standards 
now being 


developed 
is that 
many 
vendors 
can now create 
languages 


that 
will 
operate 
effectively 
on the same operating 
system. 


The 
software 
bus concept 
provides 
these vendors 
assurance 


their 
languages 
will operate. 
and it also provides 
J-LC users 


with 
a significantly 
broader 
range or application 
languagcs 


and 
even 
pre-developed 
software. 
Among 
the ncwer 
com- 


puter 
languages 
currently 
underdevelopment 
by independent 
software 
vendors'as 
a result of the UDI/URI 
standardization 
are BASIC. 
COBOL. 
and "C". 


This 
one development 
~ 
thc standardization 
of software 


development 
and runtime 
environments 
- 
has the potcntial 
to be as signific~nt 
to J-LC 
users 
as earlier 
efforts 
to stand- 


ardize 
on communications 
methods 
(such 
as the IEEE 488 


standard) 
or J-LC standardization 
such as thc Multibus 
(IEEE 


P796). 
Once 
a standard 
is dcveloped 
and accepted. 
many 


different 
manufacturers 
can develop 
products 
with the assur- 


ance that they will be compatible 
with other products. 
Hence. 


the user obtains 
a broader 
selection 
and applications 
innova- 


tion 
is enhanced. 
Moreover. 
users need concentrate 
only on 
learning 
one approach. 
with a corresponding 
improvement 
in 


speed 
and productivity 
of applications 
efforts. 


Standards 
for 
J-LC 
Networks. 
Increasing 
use of VLSI 
means 
that 
J-LC costs per function 
are declining. 
A, a result. 
many 
new 
applications 
will become 
cost-effective. 
One of 


the major 
new application 
areas VLSI is stimulating 
is local 
area 
networkine. 
The costs of J-LCSand supporting 
memory 


are now 
declining 
to the point 
wherc 
local and even 
global 
area 
networks 
make 
more 
and more 
,-;ense. As networking 


becomes 
more 
practical. 
however. 
new approaches 
to net- 


working 
standards 
will be required. 


intel 


Standards 
are particularly 
important 
for networking 
J.LC 


operating 
systems. 
since 
the operating 
system 
will 
be re- 


quired 
to manage 
many of the networking 
resources. 
In this 


regard, 
Intel Corp, 
Xerox Corp, 
and Digital Equipment 
Corp 
have 
joined 
together 
to develop 
Ethernet, 
a local 
area net- 
work 
standard. 
(Many 
other 
firms 
are also 
becoming 
in- 


volved 
with Ethernet, 
including 
Hewlett-Packard, 
Siemens, 


Nixdorf. 
Olivetti. 
and Zilog.) 


One of Intel's 
Ethernet 
responsibilities 
is to provide 
stand- 


ard 
modules 
and 
standard 
interfaces 
for 
Ethernet 
users. 


These 
include 
high 
level, 
data 
link 
layer 
interfaces 
to an 


Ethernet 
controller 
on the standard 
Multibus, 
a new Multi- 
bus Interprocessor 
Protocol 
(MIP), 
and a method 
to support 


Ethernet 
with the iRMX 
86 operating 
system 
in conjunction 


with Intel's 
new Multibus 
Message 
Exchange 
(iMMX). 
Intel 


intends 
to provide 
VLSI implementations 
of these standards, 


up to the data link layer. As futher Ethernet 
standards 
evolve. 


the major 
benefit 
to networking 
J.LC users will be the ability to 
take 
advantage 
of a wide variety 
of products 
with the assur- 
ances 
they will work together 
effectively. 


Protection of Software 
Investment. Many J.LC users have 


substantial 
investments 
in J.LC software 
and are consequently 


concerned 
that 
these 
investments 
do not become 
obsolete 


before 
having 
provided 
an adequate 
return on the resources 
invested. 
Many 
current 
minicomputer 
users. 
for example. 
would 
like 
to take 
advantage 
of the density, 
size, 
and low 


cost per function 
benefits 
of J.LCS but are hesitant 
to redevelop 
their 
existing 
application 
software. 


Recent 
developments 
in J.LC software 
are directed 
toward 


solving 
this concern. 
The 
trends 
toward 
software 
and net- 
working 
standards, 
for example, 
will 
provide 
a basis 
for 


rapid 
development 
of new language 
compilers, 
and emula- 
tors that allow 
minicomputer 
users to migrate 
to more tech- 


nically 
advanced 
J.LCS without 
a commensurate 
reinvestment 


in software 
development. 


Other 
trends 
in J.LC operating 
systems, 
such as increasing 


modularity 
and configurability, 
also support 
this direction. 


Intel's 
iRMX 
86 operating 
system, 
following 
this trend, 
is 


developed 
in 
modules. 
This 
allows 
future 
integration 
of 


certain 
modules 
into silicon 
as condItions 
warrant. 
Modular- 


ity and configurability 
also mean users can eliminate 
portions 


of the operating 
system 
not appropriate 
to their application 


without 
a performance 
penalty. 
In addition, 
Intel's 
approach 


to operating 
system 
design 
means 
that current 
J.LC systems 


users 
can 
easily 
and 
cost-effectively 
move 
most 
of their 


existing 
software 
from 8 bit to 16 bit J.LCS as their application 


requirements 
expand. 
This 
design 
consideration, 
most 


noticeable 
in the 
iRMX 
86 operating 
system, 
guarantees 


substantial 
user 
software 
investments 
are 
protected 
while 


users 
can, 
at the same 
time, 
rapidly 
take advantage 
of the 


latest 
developments 
in VLSI technology. 


hardware 
advances 
mean change 


Rapidly 
advancing 
developments 
in J.LC technology 
are caus- 


ing a corresponding 
change 
in J.LC operating 
systems. 
More 


and 
different 
operating 
systems 
are becoming 
available 
as 


users' 
needs 
evolve 
and become 
more specialized. 


The rapid march 
of VLS I technology 
also pressures 
manu- 


facturers. 
OEMs. 
and 
end 
users 
to develop 
and evaluate 


operating 
systems 
based 
on their ability 
to directly 
translate 


VLSI 
advances 
into applications. 


Moreover. 
the 
need 
for 
a series 
of operating 
systems 


standards 
is clear. 
Without 
standards 
such as the UDI and 


UR1. 
operating 
system 
development 
could 
retard 
the wide- 


spread 
and fast growing 
u'se of productive 
microelectronics 


technology. 
Il) 
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The overall structure 
01 the iRMX 86 Operating System 


... 
an O.S. designed 
to exploit the advantages 01 


Intel's 
VLSI technology. 


Over the past several 
years, 
microcomputers 
have become 
faster and less expensive. 
Accompanying 
this increase 
in 
raw horsepower 
have been enhancements 
in hardware 
ar- 
chitecture 
including 
high-speed 
floating-point 
co- 
processors, 
multiple 
processor 
support, 
and soon, 
Local 


Area Network controller 
chips. 


This rapid increase 
in VLSI capability 
poses a question 
to 


microcomputer 
users: How do they keep up? Already, 
the 


cost of developing 
and maintaining 
software 
packages 
is 
many times more than the cost of developing 
the underlying 


hardware. 
Fortunately, 
microcomputer 
vendors have recog- 


nized the problem. 
Some of the things they can do to help 


include: 


- 
Provide a wide variety of operating 
system features as 


a set of user-selectable 
building blocks. 


- 
Provide 
software 
that allows 
the application 
to take 


advantage 
of multiple 
processors 
for increased 
appli- 


cation throughput. 


- 
Provide software that supports the use of the Ethernet' 
protocol. 


-Integrate 
operating 
system and hardware 
functions 
on 


the same VLSI component. 


-Support 
standard 
interfaces 
that make it easy to move 


appl ication 
packages 
from one operating 
system 
to 


another and to take advantage 
of future generations 
of 


VLSI. 


The iRMX 86 Operating 
System and supporting 
Intel sub- 


systems 
provide these capabilities. 
By taking advantage 
of 


them, users can turn the "future 
shock" of VLSI to their ad- 


vantage. 
As such, the iRMX 86 product can be described 
as 
a VLSI operating 
system. 


This 
paper 
provides 
an overview 
of the features 
of the 


iRMX 
86 Operating 
System. 
Associated 
papers 
describe 


how its capabilities 
are used to support multiple processors 


[10] and Ethernet 
[11, 12]. Another 
paper describes 
how 


many of the basic features of the operating 
system are being 


integrated 
with hardware 
functions 
[13]. 


THE iRMX 86 OPERATING 


SYSTEM 


PURPOSES 
OF MICROCOMPUTER 
OPERATING 
SYSTEMS 


Because 
software 
costs are rising while hardware 
costs are 


falling, microcomputer 
customers 
have discovered 
that they 


must carefully 
account 
for their software 
development 
in- 


vestment. 
This accounting 
must include 
both the original 


development 
and the maintenance 
of the software. 
Many 


microcomputer 
users have found that it is much cheaper to 


purchase 
software 
rather 
than 
develop 
software 
from 


scratch. 
An operating 
system 
allows 
customers 
to save a 


significant 
amount 
of time and money 
in developing 
their 


particular 
application 
program. 
By reducing 
their develop- 


ment costs, applications 
that would otherwise 
be unprofita- 


ble become profitable. 


Improved 
Portability of Applications 


Initial costs of development 
are not the only major concern 


for microcomputer 
customers. 
The cost of developing 
new 


products 
in an existing 
or new product 
line is also a key 


concern. 
When one microcomputer 
board is used to create 


an initial 
product 
offering, 
another 
member 
of the same 


board family is often used to extend the product line. This is 
true because 
Intel is constantly 
adding 
new features 
to its 


family of boards which offer new hardware 
functions 
and 


increased 
performance. 
In order to take advantage 
of new 


microcomputer 
components 
or boards, 
customers 
are in- 


terested in using as much of their existing software as possi- 
ble. The use of an operating 
system will hide many of the 


details of the underlying 
hardware 
and greatly ease moving 


an application 
to a new board. 


Maximizing 
Hardware 
Utilization 


Many applications 
allow monitoring 
and controlling 
more 


than one device. 
An operating 
system can make it appear to 


the application 
programmer 
that he has more than one pro- 
cessor 
at his disposal. 
This is accomplished 
by allowing 


more 
than 
one 
activity 
to occur 
asynchronously. 
The 


operating 
system can go further 
in providing 
mechanisms 


for communication 
and synchronization 
between 
programs 


running on the microcomputer. 


Support of Sound Development 
Methodology 


Modular 
construction 
is a key way to control 
the cost of 


software 
development 
and maintenance. 
Each module 
ide- 


ally "hides" 
or encapsulates 
the effect of major decisions 


such as how data is represented. 
Similar to structured 
prog- 


ramming, 
the modular 
design 
process 
permits 
a complex 
design to be partitioned 
into a structure of cooperating 
mod- 


ules. 
This 
both 
facilitates 
top-down 
development 
and 


simplifies 
the maintenance 
and evolution 
of large software 
systems. 
Even though users of microcomputer 
systems 
are 
usually 
familiar 
with these concepts, 
the lack of effective 
tools and tight development 
schedules 
often force them to 


take a choice between 
modular 
construction 
and quick im- 


plementation. 
High 
level 
programming 
languages 
have 
played a key role in allowing customers 
to obtain the best of 
both worlds. 
An operating 
system 
can take this one step 
further by adding facilities 
to simplify 
modular 
implemen- 
tation. 
For instance, 
it can allow the customer 
to identify 
separate 
asynchronous 
activities 
that his applications 
must 


accomplish 
and write a separate 
program 
for each of these 
activities. 
The operating 
system 
can allow these separate 
programs 
to be run as separate tasks and communicate 
with 


each other as necessary. 
When a particular 
part of the appli- 
cation is to be modified, 
the change can be isolated to one or 
a very few number 
of the original 
application 
programs. 


When 
additional 
functions 
need to be added, 
additional 
tasks can be added to the system with little or no change to 
the existing tasks. 


COMMON FEATURES OF 
MICROCOMPUTER OPERATING SYSTEMS 


The varied purposes 
of microcomputer 
operating 
systems 
have led to some relatively 
standard features. 
Following 
are 
some of the features 
provided 
by the iRMX 86 Operating 
System. 


Multitasking 
and Multiprogramming 


Based on the goals summarized 
above, a key role of a mic- 
rocomputer 
operating 
system is to allow for multiple 
prog- 
rams to execute on the same processor. 
This maximizes 
the 
utilization 
of the hardware and at the same time provides for 


modular 
construction 
of applications. 
Most importantly, 
it 


allows the application 
programmer 
to manage the complex- 
ity inherent 
in real-time 
applications 
where multiple 
asyn- 


chronous 
events are occurring. 


When 
several 
programs 
must execute 
concurrently 
(or at 


least appear 
to do so), an operating 
system 
can provide 
multitasking. 
Each 
executing 
program 
is called 
a task. 
When these tasks must execute 
in separate 
environments, 
the operating 
system can support multiprogramming 
to pro- 
vide these environments: 
The set of tasks executing 
in a 
separate environment 
can then be called a job. 


Since most real-time 
operating 
systems 
are event driven, 
they 
must 
use the interrupt 
structure 
of the underlying 
hardware. 
The operating system can provide the mechanism 
that transforms 
the hardware 
interrupts 
into events that will 


cause particular tasks to execute and service the interrupt. 
In 


this way each task need be only aware of the interrupt that it 
is managing. 


Real-time applications 
often require the use of the hardware 


timer provided by the microcomputer. 
This may be because 


they must be aware of elapsed 
time in order to accomplish 


their purpose. 
Another 
reason 
is that external 
events 
may 


not occur when they should. 
The software 
must be aware 


that they have not occurred 
and take corrective 
action. 
In 
either case the programs running as separate tasks may each 
need a separate timer. 


Many applications 
cannot predict their actual memory usage 
ahead of time. This is because 
they must deal with an un- 


predictable 
environment. 
A key part of this environment 
is 


the operator 
who invokes various functions 
of the applica- 


tion. The parameters 
provided 
by the operator 
often affect 


how 
much 
memory 
the 
program 
needs. 
Besides 
the 
operator, 
the external 
devices 
connected 
to the microcom- 


puter generate 
a variety 
of events 
to which 
the software 


must respond 
immediately. 
These 
events 
are not entirely 
predictable 
and thus the amount of memory 
required 
to re- 
spond to and control these events is not predictable. 
By pro- 
viding for dynamic memory allocation, 
an operating 
system 
can help an application 
adapt to its unpredictable 
environ- 
ment without 
statically 
allocating 
the worst-case 
memory 
requirements 
to each part of the application. 


Device Support 


Often a significant 
portion of the application 
development 


time is spent writing complex code that interfaces the appli- 
cation to vendor-supplied 
devices. 
An operating 
system can 


provide software 
that does this interfacing. 
This feature re- 


duces the customer's 
development 
cost and elapsed time. 


Operating 
systems, 
in general, 
use random 
access devices 
such as disk drives or magnetic 
tapes to store and retrieve 
information. 
The very simplest 
of these applications 
might 
only store one set of data on each device. Far more common 
than this; however, is the situation where one disk is to store 
many different 
kinds of information. 
Examples 
of this in- 
formation 
may be parametric 
information 
that affects 
the 
activity of the application, 
intermediate 
data required by the 
application 
to accomplish 
its purpose, 
and data that the ap- 


plication generates 
which will be used later. 


An operating 
system 
must manage 
the secondary 
storage 
space represented 
by the random access device. 
This man- 
agement will usually include support for dynamic allocation 
of random 
access 
space, 
automatic 
bookkeeping 
of this 
space, and naming each portion used by the application. 
In 


inter 


this way the application 
can treat a single random 
access 


unit as if it were many separate 
devices each of which can 
be randomly 
accessed. 


Many microcomputer 
applications 
involve no mass storage 
devices and thus all of the operating 
system and application 


code resides in read-only 
memory. For systems that include 
mass storage 
devices, 
this allows 
some of the code to be 
loaded into read/write 
memory and provides 
some signific- 


ant advantages 
to the programmer. 
These include 


(I) Software 
can be updated 
and distributed 
on disk or 


similar media. 


(2) If not all parts of the applications 
must execute 
con- 


currently, 
less total memory 
may be required 
if only the 


code required is loaded into memory. 


The vast majority 
of microcomputer 
applications 
involve 


some interface to a human operator. 
Many of these applica- 


tions use standard cathode-ray-tube 
terminals 
in order to ac- 


complish this interface. 
An operating 
system can reduce the 


cost of using this interface in three ways: 


I) By providing 
for common 
editing functions 
that allow 


the human operator to correct his input before it is seen by 
the application. 


2) By providing 
for the automatic 
invocation 
of the cor- 
rect application 
program 
based 
on input by the human 


operator. 


3) By providing 
functions 
that make it easy f!lr the appli- 


cation program to determine 
which parameters 
have been 


specified by the operator. 


This completes 
a general description 
of the features that are 
provided 
by iRMX 86. A detailed 
description 
of the func- 
tional capabilities 
of this operating 
system follows. 


MAJOR FEATURES 
OF THE iRMX 86 
OPERATING 
SYSTEM 


In order to provide 
operating 
system 
support 
for applica- 
tions using the 8086 microprocessor, 
Intel has developed 
the 
iRMX 86 Operating 
System.(1) 
Because the system is mod- 
ular, it allows customers 
to choose only those features of the 


operating 
system that are needed by their applications. 


The iRMX 86 Nucleus 
provides 
for multitasking, 
interrupt 


control, 
timer 
support, 
and intertask 
communication.[2] 


While many of these concepts 
are the same as in other mic- 
rocomputer 
operating 
systems 
the application 
interface 
is 


quite different. 
One reason for this is that iRMX 86 inter- 


faces encapsulate 
the details of the implementation 
so that it 


can be more easily changed 
without 
affecting 
the applica- 


tion. This encapsulation 
is accomplished 
by implementing 


each mechanism 
as a type manager. 
Each type manager 


provides 
a set of objects that are defined by their attributes 


and the operations 
that can be performed 
by them. The basic 


object 
types 
supported 
are 
task, 
segment, 
mailbox, 


semaphore, 
region, 
job, 
and extension. 
One of these ob- 


jects, 
the task, also serves as the subject 
in the sense that 


tasks are the active elements of the system and perform op- 
erations on all objects. 


Tasks. All operations 
are performed 
by tasks. 
A task is an 


executing 
program and is characterized 
by a set of processor 


register values, a priority, a containing job, and a dispatcher 
state. 


Segments. 
A segment is a contiguous 
portion of memory de- 


scribed by a base and a length in bytes. The base of a seg- 
ment can be loaded into a segment register for use as a code 
segment, 
stack segment, 
data segment, 
or extra segment. 


Mailboxes. 
Mailbox 
objects 
are used by a task when 
it 


wishes to pass an object to another task in the system. A set 
of tasks can use this mailbox to implement 
synchronization, 


mutual exclusion, 
and communication. 


Semaphores. 
Semaphores 
are used in the place of mailboxes 


where 
no actual 
information 
needs 
to be communicated 


between 
the tasks. 
Semaphores 
have the advantage 
of re- 


quiring 
less execution 
time overhead 
and thus may be a 


sound alternative 
where performance 
is critical. 
They are 


also useful in solving 
resource 
allocation 
problems, 
espe- 


cially when the number of units of the resource is large or if 
it is desirable 
to allocate several units at once. 


Regions. 
The region object type is used to implement 
criti- 


cal regions via mutual exclusion. 
Regions 
have the advan- 


tage of preventing 
the deletion 
or suspension 
of a task dur- 


ing a critical operation. 
They are also Ilsed to guarantee 
that 


a high priority 
task will not wait an excessive 
amount 
of 


time for a resource held by a lower priority task that is cur- 
rently in a region. 
This is accomplished 
by raising 
the ef- 


feciive 
priority 
of the task 
holding 
the critical 
region 


whenever 
a higher priority task is waiting for it. 


Jobs. Job objects represent 
the environment 
in which a set 


of tasks can operate. 
This environment 
is limited by the re- 


sources given to an application. 
Several different things can 


make it desirable 
to divide an application 
into multiple en- 


vironments: 


1) Co·,trol Dynamic Memory Allocation. 


When multiple 
applications 
are implemented 
on a single 


microprocessor 
the extent to which each application 
can 


inter 


account 
for the other applications' 
memory 
needs is li- 


mited. 
By providing 
separate 
memory 
allocation 
envi- 


ronments 
for each application, 
the user can allocate por- 


tions of the total memory to each. In this way he can en- 
sure that one application 
will not allocate memory to the 
disadvantage 
of others. 
This 
approach 
also 
makes 
it 


easier to avoid a key hazard of dynamic 
allocation, 
the 
possibility 
of memory deadlock. 


2) Separately 
Invoke & Abort Individual Applications 


While many applications 
only require a static set of tasks, 
some applications 
involve the dynamic 
invocation 
of in- 
dividual 
subapplications 
and require 
the ability 
to abort 


these subapplications 
at any time. By providing 
separate 


environments, 
the iRMX 86 Operating 
System allows an 


individual 
subapplication 
to be aborted 
and have its re- 


sources 
returned 
to the system 
without 
affecting 
other 


subapplications 
in the system. 


When 
multiple 
applications 
are run on the same mic- 


rocomputer, 
these applications 
are often designed 
and 


implemented 
by separate 
programming 
teams. 
When 


these teams select names for external 
devices that are to 
be used by their applications, 
they take the risk of choos- 


ing names also used by other applications. 
By providing a 


separate environment 
for each executing 
application, 
the 


names used for each application 
can be kept separate. 
At 


execution 
time the operator 
can match 
the individual 


names used by the application 
against the resources 
pro- 


vided by the operating 
system. 
A particular 
example 
of 
this concept 
occurs 
when one program 
is invoked 
more 
than one time concurrently. 
During 
each invocation 
the 


operator 
can match a set of devices 
that the application 


uses against 
a particular 
subset of the devices 
available. 
In this way the same program 
can access several 
sets of 


devices, 
at the same time, because from the point of view 


of the operating system the program is running in separate 
environments. 


Extensions. 
The final basic object type is the extension 
ob- 


ject.[9] 
The extension object is used by operating extensions 
to create 
new types. 
New objects 
of the new type can be 


created 
as a composite 
of existing 
objects. 
Operators 
are 
also provided 
for deleting 
a composite 
object and for ob- 


taining the component 
objects of a composite 
object. 


The concept 
of restricting 
access 
to objects 'is an integral 


part of the iRMX 86 model. 
When a task creates an object 


all tasks in its job are automatically 
given access to the ob- 


ject. A task can pass an object to a task in another job. Two 
mechanisms 
for communicating 
access 
to an object 
have 
been built into the iRMX 86 Nucleus: object directories 
and 


mailboxes. 
The advantage 
of object directories 
is that they 
allow a task to obtain access to an object by knowing 
only 


its name. The advantage 
of mailboxes 
is that they also can 


be used for synchronization 
and communication 
between 


tasks. 


To increase 
the ease in which programs 
can be debugged, 
each iRMX 
86 function 
returns 
an exception 
code. 
This 
code indicates 
whether 
the requested 
operation 
was suc- 


cessfully 
performed, 
and if not, what went wrong. 
These 


exception 
codes may be handled 
either by instructions 
im- 


mediately 
following 
the call to the operating 
system or by a 
separate error handler. In the latter case, an error condition 
will 
automatically 
cause 
control 
to transfer 
to a user- 


provided routine or, by default, 
to one provided 
by the sys- 


tem. 


The Terminal 
Handler 
provides 
a real-time, 
asynchronous 


interface 
between 
a terminal 
and tasks running 
under the 
supervision 
of the Nucleus.[3] 
It can be used either with or 
without 
the Debugger. 
The Terminal Handler 
provides 
the 


following 
features: 


• Line editing 
• Multicharacter 
type-ahead 


• Control characters 
for suspending 
and resuming 
output 
at the terminal 
• A means of awakening 
the Debugger. 


The Terminal Handler can be accessed either directly under 
the supervision 
of the Nucleus 
or through 
the Basic 
I/O 


System described 
later. 


Debugger 


The Debugger 
is designed 
specifically 
for debugging 
and 


monitoring 
systems 
running 
under 
the supervision 
of the 


Nucleus.[4] 
A special 
Debugger 
is very helpful 
in debug- 


ging such systems because their real-time and multi-tasking 
characteristics 
render 
useless 
many 
ordinary 
debugging 


techniques. 
The iRMX 86 Debugger 
is sensitive to the data 
structures 
used by the Nucleus and can give "snapshots" 
of 


tasks at critical 
moments. 
It can also be used to alter the 


contents 
of memory. 
If desired, 
the Debugger 
can be in- 
cluded 
in a debugged 
application 
system 
for trouble- 


shooting in the field. If it is included the Debugger 
requires 
only the support of the Nucleus 
and the Terminal Handler. 


Basic I/O System 


The iRMX 86 Basic I/O System provides 
facilities 
for ac- 


cessing 
devices 
and files residing 
on random 
access 
de- 
vices.[5] 
By taking a modular 
approach, 
it allows the cus- 


tomer to choose between 
support for physical devices 
such 


as terminals 
and random 
access devices, 
and sophisticated 


support 
for files 
on the random 
access 
devices. 
It ac- 


complished 
this goal by providing 
two types of drivers. 


inter 


The first are device drivers. 
Device drivers 
allow the cus- 


tomer to choose from the set of Intel-provided 
device driv- 


ers in order to support the controllers 
that are being used. In 


addition, 
the customer 
can add his own device 
drivers 
to 
match custom device controllers. 


The second 
type of driver 
is called 
a file driver. 
The file 


driver accomplishes 
goals similar to a device driver in that it 


is a modular piece of the VO System which allows the cus- 
tomer just those facilities 
needed 
by his application. 
File 


drivers implement 
different types of files. 


Named files. 
The most general type of file provided 
by the 


iRMX 86 Basic VO System is that of a named file. A named 
file is a byte-oriented 
random-access 
file which is given a 


name to identify 
it among 
those 
on a particular 
volume. 


Files can serve as both data files and directories. 
Directories 


can point to both data files and directories. 
In this way a file 


can be designated 
by a sequence of file names from the root 


or main directory 
on a volume through a sequence of direc- 


tory files to the actual file being designated. 
Once located, 
a 


file can be opened 
and closed 
as many 
times 
as desired 


without further directory 
searches. 
This type of file naming 


mechanism 
is called a hierarchical 
file structure. 


The accessing 
of the individual 
data blocks of a file is de- 


signed to both minimize allocation of space on a volume and 
to minimize 
the number of disk accesses required to access 


an arbitrary 
location 
in a file. For small files an arbitrary 


data block can be read with a single physical seek-and-read 
operation. 
In large files this can be accomplished 
with at 


most, two seek-read 
combinations. 
Because there is inevit- 


ably a trade-off 
between 
space and performance, 
the Basic 


VO System allows the application 
to specify to what extent 


space 
should 
be compromised 
for performance 
or vice 


versa. 


Physical files. 
The second major type of file provided by the 
Basic VO System is the physical file type. Physical files are 
accessed similiarly to physical devices. 
In order to provide a 
common interface to a wide variety of devices the interfaces 
to physical 
files assumes 
that any byte on a device can be 


accessed. 
The device 
driver 
for a particular 
device 
then 


chooses to what extent it supports 
this file. For instance, 
a 


device driver for a line printer would return an error upon a 
request for seek or read. 


Stream files. 
A third type of file provided 
by the Basic VO 


System is called stream files. A stream file is a sequence of 
bytes. 
A task can add bytes to the end of this sequence 
of 


bytes and/or 
read bytes from the front of the sequence 
of 


bytes. Any bytes read are consumed 
by the read operation 


and thus can only be read once. A key use of string files is to 
allow a program that normally writes to a physical device or 
to a disk file to direct its output to another program. 


Because the Basic VO System provides three basic file driv- 
ers which are accessed 
via a common 
interface, 
application 


programmers 
do not have to be concerned 
whether the data 


that is being output is being written to a physical 
device, 
a 


data file, or directly to another program. 


Extended 
I/O System 


The iRMX 
86 Extended 
I/O System[6] 
builds 
upon 
the 


facilities provided by the Basic VO System and provides the 
additional 
facilities to accomplish 
two general goals: 


I) decreasing 
the cost ·of implementing 
applications 
that 


use the facilities of the Basic VO System. 


2) providing additional features not found in the Basic VO 
System. 


The fact that the Basic VO System 
is designed 
to be very 


general means that some of its system calls are overly com- 
plex when 
used 
in simple 
situations. 
The Extended 
I/O 


System 
provides 
an optional 
interface 
that allows 
calling 


sequences 
to be greatly 
simplified 
when some of the more 
sophisticated 
features 
of the Basic 
I/O System 
are not 


needed. 


One of the additional facilities provided by the Extended VO 
System is the notion of logical names. Logical names allow 
applications 
to refer to devices 
without 
using 
the actual 


physical names of the devices. This allows an application 
to 


be written for a standard set of devices and then be executed 
with a variety of different 
devices. 
This accounts 
for both 


the fact that the user of an application 
program 
will vary 


over time and the fact that the set of available 
devices 
will 
change 
over time. The Extended 
VO System 
also extends 


the concept 
of logical names to include directory 
files and 


data files. In this wayan 
application 
program can refer to a 


device location without knowing 
whether 
it is using an en- 


tire physical 
device, 
a directory 
on that device, 
or a par- 


ticular data file on that device. 
Consequently 
a data file can 


be substituted 
for a device like a line printer or a directory 


on a large disk can be substituted 
for a smaller disk. 


The Extended 
I/O System provides 
support 
for automatic 


buffering 
as an optional 
facility. This support accomplishes· 


two goals. 


I) Allow the physical accesses to the devices to match its 
physical 
characteristics. 
In particular, 
it allows 
the 


number 
of bytes 
requested 
of the device 
to match 
the 


characteristics 
of the device such as its sector size. 


2) Allow the physical 
access of the device to be concur- 


rent with the execution 
of the application 
program. 
In this 


way the throughput 
of the system 
can be increased 
by 


overlapping 
CPU and VO time. 


intJ 


The first goal is accomplished 
by having the Extended 
VO 


System 
allocate 
a buffer whose 
size matches 
the physical 


characteristics 
of the device. 
Input and output requests 
are 


accomplished 
using 
the buffer 
or buffers 
as intermediate 


storage. 
In this way the actual request 
made to the device 


controller 
matches 
the controller, 
and is independent 
of 


what the application 
has requested. 


The second goal is accomplished 
by providing 
one or two 


buffers 
where data can be moved 
to and from at the same 


time the application 
is executing. 
To use the example of se- 


quential input, when the file is open, the Extended VO Sys- 
tem can initiate reads into the buffers that it has allocated for 
the application. 
When 
the application 
makes 
its first re- 


quest, the data it needs may already be in one of those buf-. 
fers and can be returned 
immediately 
to the application. 
By 
the time the data in the first buffer is exhausted 
the second 


buffer 
may have been filled. 
While 
the second 
buffer 
is 


being used the Extended 
I/O System can refill the first. In 


this way, assuming 
that the execution 
time required 
to pro- 


cess a buffer full of information 
is comparable 
to the time 


required to read from the disk, the application 
will run con- 


currently 
with the physical reading of the device. The same 


approach can be used for sequential 
output, 
in this case the 


physical writing is delayed until the buffer is filled. 


By combining 
the notions of automatic 
buffer size and au- 


tomatic 
overlap, 
the total throughput 
of the system can be 


increased 
and the execution 
time of a particular 
application 


can be decreased. 
The Extended 
I/O System provides 
both 


these facilities in a way that makes them appear as if the ap- 
plication 
is doing a simple sequence 
of reads and writes. 
It 


completely 
hides the buffering 
and the overlap 
algorithm 


from the application. 


Application 
Loader 


The Application 
Loader 
uses the I/O System 
that to load 


object files into memory[7]. 
With the loader, you can store 


some of your code on disk and load it into memory 
only 
when you actually 
need it. This can lower the memory 
re- 


quirements 
for your application 
system. 


The Application 
Loader accepts the following types of 


files: 


1) Absolute 
Files: The loader 
places absolute 
code into 


memory at predetermined 
locations. 


2) Load lime Locatable 
(LTL): These files contain 
code 


which the loader can assign to any available 
memory 
in 


the job's 
memory 
pool. This version 
of the loader 
will 


automatically 
update 
instructions 
as they are loaded 
to 


account 
for the fact that in a multi segment 
program 
the 


code in one segment may refer to code and data in other 
segments. 
Since the loader is responsible 
for allocating 


the segments, 
it can update the code with the appropriate 


base values while it is loading the code. 


The Application 
Loader also supports overlays. 
This allows 


an application 
to be constructed 
as a "root" 
and a set of 
overlays. 
This significantly 
reduces the amount of memory 


required to support large applications. 


The iRMX 
86 Operating 
System 
provides 
an additional 
layer of software called the Human Interface.[8] 
This layer 
makes 
it particularly 
easy for customers 
to add customer 
facilities to the system. 
It is designed to provide support for 


interactive 
commands 
whose code is usually not resident 
in 
memory. In addition to this goal it provides a standard set of 
commands 
for the manipulation 
of files. 


In order 
to make it easy to add custom 
commands 
to the 


system, 
the Human 
Interface 
provides 
fO,1automatically 


loading and invoking the appropriate 
program based on the 


commands 
entered 
by the operator. 
Once 
a program 
is 


loaded and invoked in this way, it can access its parameters 
by making a series of calls to the Human Interface 
routines. 


These 
routines 
will return 
connections 
to files as well as 


other parameters. 


Rather than require each customer to implement 
his own set 
of basic commands, 
the Human Interface 
provides 
a stan- 


dard set of file manipulation 
commands. 
This set of com- 
mands 
includes 
commands 
for renaming 
files, 
copying 


files, displaying 
a list of the files in a particular 
directory, 


creating files, changing 
access to files, and deleting files. 


Bootstrap Loader 


The iRMX 86 Bootstrap Loader[7] 
is used to load the iRMX 


86 system and/or application 
programs 
into memory 
from 


mass storage 
and begin their execution. 
It consists 
of two 


stages. 


The first stage provides 
a rudimentary 
device 
driver 
and 


uses it to read in the first part of the second stage. In addi- 
tion, the first stage may provide 
a file name to the second 


stage to identify which version of the system is to be loaded. 
The first stage may also provide 
for automatic 
or manual 
bootstrap 
device selection. 


The second stage reads the rest of itself in and then finds and 
loads the operating system. Using the device driver from the 
first stage, the second stage interprets 
the file structure 
on 
the disk. Since the first stage and device driver handle 
all 


the device dependent 
matters, 
the same second stage can be 


used on all iRMX 86 disks regardless 
of the type of device 


used. 
Separately 
located 
modules 
may be combined 
in a 


library, 
so that the various 
layers of the operating 
system 
and the application 
may be loaded from one file. 


This paper has outlined 
the advantages 
of vendor-supplied 


operating 
systems 
software 
for microcomputers. 
Although 


these advantages 
parallel 
those used for operating 
systems 
in minicomputers 
and mainframe 
computers, 
the specific 
facilities 
required 
by a microcomputer 
customer 
are often 


different. 
For example, 
many microcomputer 
applications 
do not require 
operating 
system 
support 
for devices 
and 


files. The iRMX 86 Operating 
System answers this need by 
providing 
layered 
software. 
It is organized 
around a basic 
Nucleus 
that supports 
multitasking 
and offers I/O facilities 
as optional 
layers 
above 
this Nucleus. 
A customer 
can 


choose how many of these facilities he requires and then add 
his application 
software on top of the operating 
system. 


By taking this approach 
iRMX 86 reduces 
the investment 
required by the customer, 
improves 
the portability 
of appli- 
cations 
from one microcomputer 
to another, 
allows 
one 
microcomputer 
to be used for multiple 
concurrent 
applica- 
tions, 
and provides 
a model that makes 
it much easier 
to 
change and add features. 


The dramatic 
increase 
of computing 
power 
provided 
by 
microcomputers 
represents 
a challenge. 
How can this power 


be harnessed 
without 
turning 
the entire 
labor force 
into 
computer 
programmers? 
Part of the answer 
is provided 
by 
vendor-supplied 
operating 
systems. 


By taking 
advantage 
of the 
availability 
of both 
high- 
performance 
microcomputer 
hardware 
and off-the-shelf 


software, 
designers 
can leverage their expertise 
and invest- 


ment. End-users 
can quickly and effectively 
put microcom- 


puters 
to use in their 
applications. 
Original 
Equipment 


Manufacturers 
can take advantage 
of what they know best, 
their market and their technology. 
In this way, they can play 
a leadership 
role in taking the microcomputer 
revolution 
to 
their marketplace. 
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AN OBJECT ORIENTED 
OPERATING SYSTEM 
FOR MICROCOMPUTERS 
Organizing an operating system around a set of object 
managers allows designers to tailor the software to the 
application, 
not vice versa 


by John P. Collins 
and 
Miles M. Lewitt 


O 


perating 
systems 
and 
the 
various 
programs 
and 


programming 
systems that run under 
their control 


are all tools 
for manipulating 
information. 
Tradi- 


tionally, 
these software 
tools are conceived 
and imple- 


mented 
as systems 
of procedures 
that manipulate 
data 


of various 
types. This is really an extension 
of the fun- 


damental 
nature 
of most computer 
hardware-work 
is 


performed 
by causing 
various 
instructions 
to operate 


upon 
assorted 
types 
of data. 
It is the programmer's 
responsibility 
to ensure 
that 
the data 
can be meaning- 


fully manipulated 
by the instruction. 
As the use of computers 
becomes 
more widespread, 
and the complexity 
of software 
increases, 
there is added 


motivation 
to discover ways of making the programming 


task easier, 
and programs 
more reliable 
and adaptable 
to differing 
environments. 
Because of this, a great deal 


of interest 
has developed 
in the 
various 
design 
tech- 


niques 
of 
programs 
and 
programming 
systems, 
with 


most of the emphasis 
on the structuring 
of procedures 


and the relationships 
among 
them. 
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iRMX 286 operating 
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Systems; 
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cp·s operating 
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information 
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Object 
orientation 
is a programming 
methodology 


that embodies 
a different 
view of computer 
software. 
In 


an object 
oriented 
system, 
things 
happen 
as a result of 


interactions 
between 
objects-where 
an object 
is com- 


posed 
of one 
or more 
types 
of data. 
An 
associated 


object 
manager 
performs 
all of the operations 
defined 


on 
this 
data. 
The 
object 
is 
still 
manipulated 
by 


procedures, 
but 
is directly 
manipulated 
only 
by the 


procedures 
that 
are 
a part 
of 
the 
object 
manager. 


Information 
is manipulated 
in an object oriented 
system 


by issuing 
requests 
to object 
managers 
to perform 
the 


desired 
operations. 


Intel's 
iRMX 86 operating 
system is an object 
oriented 


operating 
system 
designed 
to run on the Intel iAPx 86 


and 
88 families 
of microprocessors. 
It provides 
several 


basic 
object 
types 
that 
implement 
the 
fundamental 


operations 
required 
of an operating 
system. In addition, 


it allows for the definition 
of new object types, enabling 


it to be custom 
tailored 
to suit individual 
needs. 


Background 
Structured 
programming 
methodologies 
were developed 


in an attempt 
to enable 
programmers 
to consistently 


produce 
more reliable, maintainable 
software 
with lower 


overall costs for program 
development 
and maintenance. 
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operating systems, 
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Mr Lewitt 


has an MS in computer 
science from 
Arizona 
State 


University, and a BS in computer 
science from 
the City 


College of New 
York School of Engineering. 


In order to achieve these goals, structured 
programming 
methodologies 
allow large, complex systems to be better 
understood, 
through 
techniques 
of top down 
design, 


decomposition, 
and stepwise refinement. 


Structured 
programming 
techniques 
primarily 


address 
the flow of control 
within 
systems and indi- 


vidual programs. 
The decomposition 
of programs 
into 
modules 
with 
well 
defined 
interfaces 
is 
achieved, 
typically, 
by breaking 
out each major 
processing 
step 


into a module, 
and rigorously 
defining 
the interfaces 
between 
them: 
parameters, 
data 
structures, 
table 
organizations, 
and the media used to represent the data; 


all represent 
decisions that must be made carefully. 


This decomposition 
of programs 
into easily under- 


stood, 
manageable 
modules 
has helped 
produce 
pro- 


grams that are more easily developed, 
more bug-free, 
and, 
in general, 
more 
easily 
maintained. 
However, 


because of emphasis on the use of control flow in deter- 
mining program 
modularization, 
it is quite possible to 


construct a well structured 
program that is as difficult to 


modify as a monolithic, 
totally unstructured 
program. 
This can easily occur when a program 
change, 
which 


involves modification 
of the representation 
of a pro- 


gram's 
data is required, 
or a change is required 
in the 


media or its method 
of access. 


Object 
orientation 
provides 
a 
methodology 
that 


extends the concepts underlying conventional 
structured 


programming 
by also structuring 
the knowledge of how 


data 
are represented. 
It is an approach 
to program 


development 
in which an attempt 
is made to hide data 


representation 
and design decisions that are likely to be 


changed. 
This is achieved by an approach 
to program 


modularization 
that 
minimizes 
the number 
of proce- 


dures that are aware of how a particular 
type of data is 


structured 
or represented, 
and that groups 
these pro- 


cedures together 
with their data as a module. 


The primary difference between 
conventional structured programming 
and object oriented programming is 
the number of modules directly 
manipulating each data structure. 


Overall structure of a program is still broken down in 


terms of the steps it involves, but the resulting modules 
are designed to use data by making requests of object 
managers 
rather 
than 
manipulate 
data 
structures 
by 


directly 
accessing them. 
Only the procedures 
directly 


associated 
with an object manipulate 
the object's 
data 


structure. 
Although 
the data associated 
with an object 


may be used by many modules, there is only one module 
with the necessary 
knowledge 
required 
to access that 


data 
directly. 
This 
module, 
called 
an 
object's 
type 


manager, 
contains 
procedures 
to 
perform 
all 
the 


manipulations 
that are required by other modules in the 


system. As a result, any changes to the structure or rep- 
resentation 
of the data associated with an object require 


changing only the procedures 
in the object's 
type man- 
ager, rather than all procedures 
in the program 
which 


use the data. 


Several 
programming 
languages 
and 
systems 
now 


support 
the object oriented methodology. 
SMALLTALK, 


from the Xerox Palo Alto Research Center, is an object 


oriented programming 
system in which object types are 


referred to as classes and the procedures 
associated with 


an object are termed 
methods. 
The Ada programming 


language supports object oriented programming 
with its 


package construct. 
The Intel iAPX 432 processor 
incor- 


porates 
object orientation 
into its basic design. Intel's 


iRMX86operating 
system is itself constructed 
as an ob- 


ject 
oriented 
system 
with the ability 
to support 
the 


definition 
of new object types. This system provides its 


users with flexibility in dealing with a broad 
range of 


possible applications 
of today's very large scale integra- 


tion (VLSI)technology. 


Methodology 
To better understand 
how object oriented programming 


differs from the more conventional 
methodologies, 
it is 


helpful 
to 
examine 
the 
construction 
of 
a 
sample 


program. 


For a sample program, 
consider a simple card catalog 


generating 
program 
that an average size library might 


use. Every month, 
the hypothetical 
library 
acquires 
a 


number of new books. 
As each is received, the appro- 


priate card catalog 
information 
is entered 
into a new 


books file. Each entry begins with the book's 
subject 


category 
(agriculture, 
physics, 
fiction, 
etc) and 
card 


catalog 
number 
followed 
by a comma, 
the author's 


name, 
a second comma, 
and the book's 
title. 
Subse- 


quent 
items of information 
follow, 
in a fixed order, 


with 
each 
item 
separated 
from 
the 
preceding 
by a 


comma. The program is run once a month, with the new 
books file as input. It produces two print files as output. 
One is a list of card catalog entries destined for manual 
insertion 
into the library's 
subject 
catalog; 
these are 
sorted by subject, 
alphabetically. 
The other is a list of 
card 
catalog 
entries 
destined 
for 
the 
author/title 
catalog. 
Each entry 
in this list begins with either 
an 


author's 
name (last name first) or a book title, and the 


entire list is sorted 
alphabetically 
on the first field in 


each entry. Using conventional 
structured 
programming 


techniques, 
an organization 
of program modules similar 
to Fig I is a probable 
result. 


Processing 
begins with the input module reading the 


new books file entries and storing them in memory 
in 


the catalog entry table. This is done to make the fre- 
quent use of this information 
as efficient 
as possible. 


Next, the subject sort module 
is invoked. 
It scans the 
catalog entry table and produces 
a subject index table, 


which contains the numbers (indices) of all the entries in 
the 
catalog 
entry 
table, 
sequenced 
to 
reflect 
their 


alphabetized 
order when sorted by subject name. This is 


done in order to conserve memory, 
since the individual 


entries in the catalog entry table may contain over 100 
characters. 
The author 
and title sort modules are then 
invoked, 
in turn, 
to produce 
similar 
index tables 
for 
alphabetically 
accessing 
the 
catalog 
entry 
table 
by 


author 
and title. Next in sequence 
is the author/title 


merge module, which merges the author and title index 
tables to produce a single alphabetized 
index table and 
associates a type (author 
or title) with each index. The 
final two modules of the program 
use the subject and 


author/title 
Intel tables, in conjunction 
with the catalog 
entry table, 
to produce 
properly 
formatted 
print 
files 
for the two card catalogs. 


This implementation 
follows guidelines for modular- 
ization that are common 
to all methods 
of structured 


programming. 
The prograrri is broken 
down into several 


modules 
with well defined interfaces 
and no side effects. 


Each 
module 
performs 
a function 
that 
can 
be 
well 


understood, 
easily programmed, 
and verified 
as to its 


correct 
functioning. 
However, 
this program 
fails miser- 


ably because 
it is not easily maintainable 
in a changing 


environment. 
Assume 
that 
the 
hypothetical 
library 
grows 
substantially, 
receiving 
many 
more 
new books 
per month, 
but, 
for various 
reasons, 
cannot 
run 
the 


catalog 
updating 
program 
more 
frequently. 
The 
new 


books 
file grows in size so that it frequently 
will not fit 


in available 
memory. 
. 


Ideally, 
a conceptually 
simple change to the program 


is all that 
should 
be required 
to solve this 
problem. 
Simply 
have the input 
module 
test the size of the file 


and, 
if it will not 
fit in available 
memory, 
create 
the 


catalog 
entry 'table' 
in a disk file, and have subsequent 


steps in the program 
access it there. 
This is not the best 


solution, 
because 
of the substantial 
effort 
involved. 
In 


fact, 
this "simple" 
change 
will affect 
every module 
of 


the example 
program 
significantly, 
except 
perhaps 
for 


the driver. 
Assume 
that the example 
program 
was implemented 


following 
an object 
oriented 
methodology. 
Such a pro- 


gram 
would 
have 
much 
in common 
with the conven- 


tional 
implementation. 
The 
functional 
decomposition 


will be the same and the same algorithms 
and data struc- 
tures will be used, but the way in which the program 
is 


modularized 
will be subtly, 
but significantly, 
different. 
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The conventional 
approach 
is to split each major pro- 


cessing step into a program 
module. 
The object oriented 


approach 
augments 
this process by also using the hiding 


of design decisions, 
most notably, 
the representation 
of 


data, 
as a criterion 
for modularization. 


For example, 
in the conventional 
implementation, 
all 


of 
the 
program 
modules 
except 
the 
driver 
directly 


manipulate 
the catalog 
entry table. 
Thus, 
all are aware 


of its structure 
as an array 
of formatted 
lines of text 


stored 
in memory. 
In an object 
oriented 
implementa- 


tion, 
the catalog 
entry table would 
be hidden 
within 
a 


module 
that 
also 
contained 
all 
of 
the 
procedures 


required 
by other modules 
to use the data represented 
in 


the table. 
For this example, 
the catalog 
entry 
module 


would support 
the following 
operations: 


INIT 
Defines the catalog entry object as empty, 
sets number of entries to zero 
Appends an entry to the catalog entry 
object, and increments number of entries 
Returns the number of entries (#ENTRIES) 
in the catalog entry object 
GET_ 
ENTRY 
Returns the indexed entry in the catalog 


(index) 
entry object 


The 
subject 
sort 
module 
now implements 
the subject 


table object, 
and supports 
die following 
operations: 


ADD_ENTRY 
(entry) 
HOWMANY 


CREATE_SUB- 
JECT_ 
TABLE 
Builds the subject table object (formerly 
the subject index table) by repeatedly 
calling GET_ 
ENTRYin the catalog entry 


module and storing the indices in 
alphabetically sorted order in the subject 
table object 


GET_ 
SUBJECT(n)Returns the text for the nth catalog entry 


in sorted order by calling GET_ 
ENTRY 


with the nth value from the subject table 


With a little imagination, 
the other 
modules 
and the 


operations 
they 
must 
support 
can 
be envisioned. 
For 


example, 
the author/title 
catalog 
output 
module 
would 


iteratively 
[from 
i = 
I to 
2*HOWMANY( 
») call the 


GET _ 
AUTH _ 
TITLE 
function 
of 
the 
author/tItle 


merge module 
to get the appropriate 
text. It would then 


format 
the text according 
to whether 
an author 
or title 


entry 
was 
being 
made, 
and 
finally 
write 
it 
to 
the 


author/title 
catalog 
print 
file. 
Fig 
2 illustrates 
the 


resulting 
program 
structure .. The 
change 
suggested 


earlier can now be easily accomplished, 
with changes 
to 


only the catalog 
entry module. 


The primary 
difference 
between 
conventional 
struc- 


tured 
programming 
and the object 
oriented 
program- 


ming is the number 
of modules 
directly 
manipulating 


each data 
structure. 
This is illustrated 
for the two ver- 


sions of the example 
program 
structure 
methodology 
in 


Figs 3 and 4. In Fig 3, information 
is shared 
via direct 


manipulation 
of 
shared 
data 
structures, 
conceivably 


requiring 
some form of mutual 
exclusion mechanism. 
In 


Fig 4, the object oriented 
system, 
information 
is shared 


through 'the common 
use of services provided 
by object 


managers. 
Module 
interfaces 
in 
object 
oriented 
systems 
are 


simpler than those in conventionally 
structured 
systems. 


They 
consist 
only 
of function 
names 
with 
associated 


parameters. 
Complex 
data formats 
and table structures 


need never be visible outside 
of a module. 
Since object 


oriented 
interfaces 
are easier to specify, 
and less likely 
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to 
require 
change, 
independent 
develQPment 
of 
the 
modules 
of a system may be more reliably 
and readily 
undertaken. 
This capability 
for easier development 
of 
more maintainable 
software 
systems is further 
enhanced 
since knowledge 
of global system data structures, 
or the 
operation 
of other modules, 
is not required 
in order to 
understand 
a given 
module. 
Structured 
programming 
helps 
to make 
programs 
and 
programming 
easier 
to 
understand. 
Object 
orientation 
takes 
another 
step 
further 
in making 
programming 
a more 
manageable 
undertaking. 


Various 
types of iRMX 86 objects 
can be divided 
into 
two categories: 
fundamental 
and composite. 
All of the 
fundamental 
object 
types are dermed 
within the system 
nucleus, 
type managers 
outside 
of the nucleus 
define 
composite 
objects. 
Each 
type 
of composite 
object 
is 
defined 
as a package 
containing 
one or more fundamen- 
tal or composite 
objects. 
Implementing 
a type manager 
for a composite 
object 
requires 
a way to package 
the 
component 
objects 
together 
into a single object, 
and a 
way to gain access to the components 
of a composite 
object. 
These 
functions 
are provided 
by the 
iRMX 86 
nucleus. 
With a few exceptions, 
most features 
of the operating 
system fit well within the structuring 
concept 
of objects. 


Generally, 
these exceptions 
do not involve 
instances 
of 
data 
structures 
that 
could 
be abstracted 
into 
objects. 
These operating 
system features 
are called support 
func- 
tions, 
an example 
of which is error handling. 
The operating 
system is structured 
as five hierarchical 
subsystems. 
Innermost 
is the nucleus, 
followed 
by the 
basic input/output 
(I/O) system, 
the application 
loader, 
the extended 
1/0 system, 
and the human 
interface 
(see 
Fig 5). Each of these subsystems 
contains 
a collection 
of 
highly related 
type managers 
and support 
functions. 


Each 
type manager 
contains 
all of the system 
calls 
required 
to 
manipulate 
a particular 
type 
of 
object. 


Always 
included 
in the system 
calls provided 
by each 
type manager 
are those 
which 
dynamically 
create 
and 


Support 
in the iRMX 88 opereting 
system 
The iRMX 86software 
package 
is an operating 
system for 
the iAPx 
86 and 
88 microprocessors. 
A distinguishing 
feature 
of this operating 
system 
is the degree of flexi- 
bility 
it 
provides 
for 
configuring 
and 
extending 
instances 
of itself. 


The operating 
system appears 
to the user as a collec- 
tion of supported 
object 
types'. For each type of object, 
the 
operating 
system 
provides 
a set of 
system 
calls 
through 
which 
that 
type 
of object 
can 
be used 
and 
manipulated. 
The object oriented 
organization 
provides 
a framework 
for learning 
the system-to 
understand 
it, 
it is only necessary 
to study the attributes 
and systems 
Fig 3 
Data manipulation in conventional program 
calls for each object 
type. 
structure. 


Fig 4 
Data manipulation In object oriented structure. 


delete an instance 
of the managed 
object type. When an 
object 
is created, 
its creator 
is given 
a l6-bit 
integer 
called 
a token, 
which 
represents 
addressability 
to the 
object. 
This 
token 
is passed 
as a parameter 
to any 
system 
call that 
operates 
on that 
type 
of object. 
The 
token 
parameter 
identifies 
the particular 
object 
to be 
manipulated. 


A 
special 
case 
exists 
for 
objects 
with 
a type 
of 
memory 
segment. 
This is the only type of object that has 
some 
of its primitive 
operations 
implemented 
in the 


hardware 
of the 
8086 central 
processing 
unit 
(CPU). A 


segment 
is specified 
to the hardware 
when its token 
is 
loaded 
into one of the 8086 segmentation 
registers. 


When 
a system 
call 
is invoked 
to 
manipulate 
an 
object, 
the operating 
system can perform 
various 
run- 


time error 
checks. 
These checks 
include 
determining 
if 


the 
value 
passed 
for 
the 
token 
parameter 
is a valid 


token, 
and if the object 
located 
by the token 
is of the 


type manipulated 
by the invoked 
system call. This run- 
time error 
checking 
is implemented 
as a configurable 
option. 


Object 
accessibility 
is an important 
issue in an object 
oriented 
operating 
system. 
When 
an object 
is initially 
created 
by the operating 
system, 
only its creator 
may 
access it. This creator 
must take an overt action in order 


to share 
an object. 
Two 
means 
are 
PTovided 
by the 


operating 
system to allow an object to be shared. 
In one 


mechanism 
the object 
is cataloged 
in a directory 
within 


a hierarchical 
directory 
structure 
that the cataloger 
has 


access to. Others, 
who have access to lookup 
objects 
in 


that directory 
and know the name the object 
was cata- 


loged under, 
can gain access to the object. 
The second 


mechanism 
allows one who has access to an object 
to 


enqueue 
it on any accessible mailbox 
object. 
Objects 
are 


queued 
on mailboxes 
in a first in/first 
out order. 
When 


a receive message 
system call is invoked 
on a mailbox, 


the object 
at the head of that mailbox's 
object 
queue is 


made accessible 
to the invoker. 


This object 
access model 
for the iRMX 86 operating 


system is not enforced 
on the 8086 CPU because 
the 
8086 


lacks 
access 
protection 
features. 
However, 
a future 


implementation 
of 
this 
operating 
system 
on 
an 
8086 


follow on microprocessor, 
that supports 
access protec- 


tion would enforce 
its object 
access mode. 


A major 
goal of the operating 
system is to provide 
a 
very flexible system. One aspect of this is configurability, 
which is provided 
by the iRMX 86 structure. 
Entire 
sub- 


systems 
can be included 
or excluded 
from a particular 


configuration. 
Within 
a 
subsystem, 
individual 
type 


managers 
and 
support 
functions 
can 
be included 
or 


excluded 
in a particular 
configuration. 
At the 
finest 


degree of granularity, 
individual 
system calls contained 


in a type 
manager 
or in a support 
function 
can 
be 


included 
or excluded 
in a particular 
configuration. 
Not 


all of the possible 
combinations 
are permitted 
or even 


make sense; however 
the user of the iRMX 86 operating 


system can generate 
a configuration 
that includes 
only 


those features 
which are needed. 
Another 
aspect 
of flexibility 
is to allow the user to 


easily extend 
the operating 
system to contain 
the addi- 


tional 
functionality 
needed 
for the specific application. 


This is accomplished 
by allowing 
the user to write sub- 


systems 
that, 
just 
like subsystems 
provided 
with 
the 


operating 
system, 
contain 
a combination 
of type man- 


agers 
and 
support 
functions. 
The 
binding 
of 
user 


written 
subsystems 
into 
the 
operating 
system 
is sup- 


ported 
by a set of system calls in the iRMX 86 nucleus. 


This set of calls are also used by the iRMX 86 supplied 
subsystems 
to bind the system together, 
independent 
of 


how the operating 
system may be configured. 


Interfaces 
between 
subsystems 
are purely procedural. 


Data structures 
and algorithms 
used by each subsystem 


are not visible outside of that subsystem. 
Thus, 
once the 


procedural 
interface 
was specified, 
design 
and 
imple- 


mentation 
of each iRMX 86 subsystem 
could proceed 
in 


parallel. 


This purely procedural 
interface 
also provides 
signifi- 


cant advantages 
during 
maintenance 
and enhancement 


Fig 5 
IRMX16operating system structure. Eacb of tbe five 


subsystems Includes type managen and support functions. 


of the iRMX 86 operating 
system. 
As long as the proce- 
dural 
interface 
remains 
unchanged, 
the 
effect 
of 
changes to code, algorithms, 
and data structures 
is 'con- 
fined. During 
performance 
tuning of the system, differ- 
ent algorithms 
and data 
structures 
could easily be tried 
to determine 
their effect on performance. 
The 
object 
oriented 
approach 
simplified 
the devel- 
oping 
and maintaining 
of the operating 
system. 
These 
advantages 
apply equally 
well to subsystems 
written 
by 
users of the operating 
system. 
Thus, 
an object oriented 
approach 
was chosen 
for the operating 
system because 
of the advantages 
it provides 
for developing 
and main- 
taining 
software, 
and because 
of the model it provides 
for building 
a configurable 
and extensible 
system. 


Example 
of an iRMX 8& type manager 
Consider 
implementing 
a type manager 
for objects 
of a 
type ring buffer. 
A ring buffer 
is an N element 
array 
into which some tasks write data, and from which other 
tasks read data. The rate of reading 
data is independent 
of the rate of writing 
data. 
Data are written 
into, 
and 
read from, the ring buffer 
in the same sequence. 
A task 
desiring 
to write into a full ring buffer 
must wait until 
space 
is made 
available 
by another 
task 
reading 
data 
from the ring buffer. 
Likewise 
a task desiring 
to read 
data from an empty ring buffer 
must wait until another 
task writes data into the ring buffer. 


One implementation 
of the ring buffer 
type manager 
would 
define 
a ring 
buffer 
as a combination 
of two 
semaphore 
objects 
and one memory 
segment 
object. 
A 


semaphore 
object is a nonnegative 
integer with two sys- 
tem calls-send 
units and receive units-through 
which 
it can be manipulated. 
The send units system call incre- 
ments 
a semaphore 
object 
by a specified 
value 
in an 
indivisible 
action. 
The 
receive 
units 
system 
call 
will 
decrement 
a semaphore 
object' by a specified 
value in 
an indivisible 
action, 
provided 
the semaphore 
remains 
nonnegative. 
Otherwise 
the 
invoker 
waits 
until 
it is 
possible. 
A segment object is an allocated 
region of con- 
tiguous 
memory. 
The semaphore 
and segment 
objects 
are two of the fundamental 
object types implemented 
by 
the iRMX 86nucleus. 
The ring buffer 
type manager 
would contain 
four sys- 
tem calls: 


• 
Create ring buffer procedure would invoke the create 
segment system call to create a segment and invoke the 
create semaphore system call twice to create two 
semaphores. It would initialize one of the semaphores to the 
number of empty slots in the ring buffer (ie, the capacity of 
this ring buffer object) and initialize the other to the number 
of full slots in the ring buffer (ie, zero). Then it would 
invoke a nucleus system call to package the three component 
objects into one composite ring buffer object, and return 
the token of this composite object to the caller. 
• 
Delete ring buffer procedure would invoke a nucleus 
system call to gain access to the three components of the 
ring buffer object. It would then invoke the delete segment 
system call to free the space for the component segment 
object, and invoke the delete semaphore system call twice, 
to free the space for the two component semaphore objects. 
Finally, it would invoke a nucleus system call to delete the 
composite ring buffer object. 
• 
Read entry procedure would invoke a nucleus system call 
to gain access to the three components of the ring buffer 
object. Next, it would invoke the receive units system call to 
decrement, by one, the semaphore containing the number of 


full slots. It would then obtain from the component segment 
object, the value of the next entry to be read. Finally, it 
would use the send units system call to increase, by one, the 
semaphore containing the number of empty slols. 
• 
Write entry procedure would invoke a nucleus system call 
to gain access to the three components of the ring buffer 
object. Then it would use the. receive units system call to 
decrease, by one, the semaphore containing the number of 
empty slots. Following this it would write the value passed 
to it into the next empty slot within the component segment 
object. Finally, it would invoke the send units system call to 
increment, by one, the semaphore containing the number of 
full slots. 


Conclusion 
Today's 
rapidly 
advancing 
VLSt technology 
is opening 
up 
broad 
frontiers 
for 
the 
application 
of 
electronic 
information 
processing. 
Through 
its extreme 
flexibility, 
ready 
availability, 
and 
unprecedented 
range 
of appli- 
cability, 
VLSI technology 
is placing 
new demands 
on 
both software 
developers 
and software 
systems. 
The 
number 
of different 
applications 
and 
environ- 
ments 
in which 
microprocessors 
can be used requires 
either a large number 
of different 
software 
systems or a 
very 
flexible, 
extensible 
type 
of system. 
This 
system 
must 
be 
versatile 
enough 
to 
be 
tailored 
or 
pieced 
together, 
to meet the differing 
requirements 
of different 
applications. 
Object 
oriented 
methodology 
is 
particularly 
well 
suited to developing 
the type of system in which there is 
a basic, required 
system nucleus, 
and a selection 
of ad- 
ditional, 
optional 
capabilities 
organized 
as individual 
object 
type 
managers. 
Most 
importantly, 
an 
object 
oriented 
system, 
like 
the 
iRMX 86 operating 
system, 
allows 
for actual 
extension 
of the operating 
system by 
individual 
users 
through 
the 
addition 
of 
new 
object 
types and type managers. 
Object orientation 
provides 
a 
means 
of effectively 
constructing 
and managing 
large, 
complex 
systems 
without 
penalizing 
small, 
simple 
systems. 
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SYSTEI DESIB./~® 


LET OPERATING SYSTEMS 
AID IN COMPONENT 
DESIGNS 


The iRMX86 operating system processor package offers 
hardware designers a set of thoroughly tested software 
primitives upon which to build present and future custom 
hardware designs 


C 


omponent 
users 
build 
application 
systems 
by 
integrating 
standard 
and 
custom 
hardware, 
soft- 
ware, 
and 
packaging. 
Microprocessors 
and 
other 
very large 
scale integration 
components 
are replacing 
much 
custom 
hardware 
with 
larger, 
more 
powerful 


standard 
hardware 
modules. 
Microprocessors 
lead 
to 
powerful 
systems, 
but 
they 
often 
require 
complex 
system management 
software. 
While this complex 
soft- 
ware 
often 
comprises 
one 
third 
or 
less of 
the 
final 
system software, 
it may require 
two thirds 
or more of 
the storage 
development 
effort. 
Worse, 
bugs in system 
management 
software 
sometimes 
do not show up until 
late 
in development 
or 
after 
the 
product 
is at 
the 
customer's 
site. 
One solution 
to this problem 
is to employ 
standard 
management 
software 
such as operating 
systems. 
More 
complex, 
multifunction 
applications 
in 
a 
realtime 
environment 
benefit 
greatly 
from 
operating 
systems. 


Examples 
of these applications 
include 
file subsystems, 
public automatic 
branch 
exchange 
(PABXJ systems, 
and 
transaction 
processing 
systems. 
But 
implementing 


George Heider 
is a senior applications 
engineer 
at 
Intel's 
OEM Microcomputer 
Systems 
Div, 5200 NE 
Elam 
Young 
Pkwy, 
Hillsboro, 
OR 97123. He works 
primarily 
with 16-bit software 
applications, 
including 
the iRMX 86 operating 
system. 
Previous 
experience 
includes 
telecommunications 
systems 
engineering, 


microprocessor 
systems, 
microprocessor 
operating 
system 
development, 
and disk storage 
system 
software. 
Mr Heider holds an MS in computer 
science 
from 
the University 
of California, 
Santa Barbara 
and 
a BSEEfrom 
Oregon 
State 
University. 


Fig t 
iRMX operating 
system 
architecture. 
Kernel 
consists 
of primitives 
also implemented 
in hardware 
in iAPX MIlO and 
iAPX 88/30 oSP. 


operating 
system 
functions 
in 
a 
component 
design 
requires 
new software 
tools, 
education, 
and expertise. 


Also, these functions 
are often specific to the particular 


design, so tools and expertise 
developed 
for one applica- 
tion are not suitable 
for subsequent 
designs. 


These 
problems 
are 
directly 
addressed 
by the 
Intel 
iAPX 86/30 and 
iAPx 
88130 operating 
system 
processors 
(asp) and the iRMX' 86 operating 
system. 
The iRMX 86is 


a full-featured, 
realtime 
multitasking 
operating 
system 
for 
iAPX 86 or iAPX 88 based 
systems. 
The 
Intel 
asp 
implements 
the iRMX 86 kernel 
functions 
in hardware 
consisting 
of an iAPX 86 or iAPX 88 central 
processor 
coupled 
with an operating 
system 
firmware 
(aSF) 
com· 
ponent, 
the Intel 80130.The aSF extends 
the base iAPX 86 
and iAPX 88 architecture 
by adding 
35 operating 
system 
primitive 
instructions 
to the 
base 
iAPX 86 or iAPX 88 
instruction 
set; systems can be built directly 
on the asp. 


System implementation 
time is thus decreased 
by having 
fully debugged 
operating 
system functions 
in hardware. 


Further 
capabilities 
can be added' by 
extending 
the set of OSP primitives 
or 
by 
integrating 
portions 
of 
the 


iRMX 86 on top of the OSP. 


Operating 
system architecture 


The iRMX 86 architecture 
shown 
in 


Fig 
I consists 
of 
the 
nucleus 
and 


layers 
for 
the 
basic 
input/output 


(I/o) 
system, 
extended 
I/O system, 
application 
loader, 
and 
human 


interface. 
The system 
also provides 


a debugger, 
a terminal 
handler, 
a 


bootstrap 
loader, 
and 
a 
patch 


facility. 


While 
the 
nucleus 
is the 
lowest 


layer of the operating 
system, 
fun- 


damental 
system 
functions 
are 


handled 
by 
the 
nucleus 
kernel, 
which 
is the core of any operating 


system. 
The kernel controls 
memory 


allocation, 
allocates 
processor 


resources, 
communicates 
between 


processes, 
and 
manages 
interrupts. 
In the Intel 
OSP these functions 
are 


implemented 
in 
hardware. 
(OSP 


functions 
are described 
in Table 
I; 


additional 
functions 
supported 
by 


the 
iRMX 86 nucleus 
are 
shown 
in 


Table 2.) Software 
development 
can 


be based 
on either 
the 
OSP or the 


iRMX 86, allowing 
software 
develop- 


ment 
to 
proceed 
in 
parallel 
with 


hardware 
development. 


In 
addition 
to 
the 
operating 


system 
primitives, 
the oSP contains 


timers 
and 
interrupt 
control 
logic 
expandable 
from 
8 to 57 interrupt 


levels. 
The timers 
include 
a system 


clock, 
user 
timer, 
and 
baud 
rate 


generator. 
The 4O-pin OSP has bus 


buffers 
and 
demultiplex 
logic, 
which 
allows' it to interface 
directly 


to the iAPx 86 or iAPX 88 multiplexed 
bus. The OSP can be located 
at any 


16k-byte 
address 
boundary 
in the 


1M-byte 
system 
address 
space. 
Application 
interface 
to 
oSP step- 


ping and revision 
levels is indepen- 


dent. A block diagram 
of the 80130 is 


shown 
in Fig 2. 
Minimum 
hardware 
requirements 
for 
the 
iRMX 86 


operating 
system shown in Fig 3 are 1.8k·bytes of random 


access memory 
(RAM), about 
16k bytes of kernel code 


memory, 
and integrated 
circuits. 
By comparison, 
the OSP 


shown in Fig 4 still requires 
1.8k bytes of RAM, but does 


not require 
the kernel code, the programmable 
interrupt 


controller, 
or the programmable 
interrupt 
timer. These are 


all replaced by the OSP. Approximately 
Ik bytes of required 


system configuration 
code are not shown in Figs 3 and 4. 


TASK 
CRE.ATE 
TASK 


INTERRUPT 
SET PRIORITY 


SET INTERRUPT 


ENTER 
INTERRUPT 


ENABLE 


DISABLE 


GET EXCEPTION 
HANDLER 


SET EXCEPTION 
HANDLER 


SIGNAL 
EXCEPTION 


Kernel functions 
Since it defines system architecture, 
application 
requests 


for system 
operations 
like interrupt 
management 
and 


memory 
allocation 
must go through 
the kernel. 
These 


Creates 
a task with 
specified 
environment 
and priority. 


Task is created 
in ready state. 
Checks 
for insufficient 


memory 
available 
within 
containing 
job. 


Deletes 
a task from 
system 
as well 
as from 
any Queues 


it is awaiting. 
Task's 
state 
and stack 
segment 
are 


deallocated, 


Suspends 
a task (changes 
its status 
to suspended) 
or 


increases 
task's 
suspension 
count 
by 1. A sleeping 
task 


may also be suspended 
and will 
awaken 
suspended 


unless 
resumed. 


Decreases 
suspension 
count 
of a task by 1. If at that 


point 
count 
is reduced 
to 0, task state 
is made ready. 
If 


it was suspend-asleep, 
it is put back to sleep. 


Puts task 
in asleep state; 
up to 10 ms units 
can be 


specified. 


Gives token 
for a task or task's 
job partition. 


Changes 
task's 
priority 
to value 
passed 
in primitive. 


Assigns 
an interrupt 
handler 
to a level. Task that 
makes 


this call is made interrupt 
task for same level, 
unless 
call 


indicates 
there is no interrupt 
task. 


Disables 
an interrupt 
level; 
cancels 
interrupt 
handler; 


deletes 
interrupt 
task for level if assigned. 


Returns 
number 
of the interrupt 
level for highest 
priority 


interrupt 
handler 
currently 
in operation 
(several 
interrupt 


handlers 
can be operating). 


Completes 
interrupt 
processing 
and sends end of 


interrupt 
signal to hardware. 


Invokes 
interrupt 
task assigned 
to a level from 
that 


level's 
interrupt 
handler. 


Suspends 
interrupt 
task 
state 
pending 
a signal 
interrupt 


from 
an interrupt 
handler. 
Used by an interrupt 
task to 


signal 
its readiness 
to service 
an interrupt. 


Sets data segment 
base for an interrupt 
handler. 


Enables external 
jnterrupt 
level. 


Disables 
an external 
interrupt 
level. 


Reads location 
and exception 
handling 
mode of current 


asp exception 
handler 
for a task. 


Establishes 
location 
and exception 
handling 
mode 
of 


current asp exception 
handler 
for task. 


Notifies 
curr~nt asp exception 
handler 
of exception. 


requests 
are made by system calls, or primitives, 
which 


are comparable 
to subroutine 
calls for system actions. 


Since the kernel manages 
much of the system hardware, 


the application 
code need not concern 
itself with many 


hardware 
details. 
This 
independence 
is not 
absolute, 


however: 
system hardware 
or resources 
not managed 
by 


the kernel still require 
application 
code. 


Basic kernel concepts 
can be explained 
using a general 


purpose 
system 
(Fig 5). Input 
data 
can be characters, 


analog 
signals, 
or 
digital 
signals; 
processing 
can 
be 


numerical 
analysis, 
editing, 
spectrum 
analysis, 
process 


control 
algorithms, 
or virtually 
any other 
transforma- 


tion. Processed 
data must be sent to an interrupt 
driven 


output 
device-a 
display, 
a 
communications 
line, 


SEND 
MESSAGE 


RECEIVE 
MESSAGE 


DELETE 
REGION 


ACCEPT 
CONTROL 


SEND 
CONTROL 


OTHER 
SET OS EXTENSION 


GET TYPE 


Communicltion 
Ind synchronizltion 
through mlilboxes 
The 
sample 
system 
needs 
a 
dis- 


patching 
algorithm 
to 
send 
the 


segments 
from task to task. 
Such an 
algorithm 
can be written 
without 
an 


operating 
system. 
For example, 
the 


input 
task can fill a buffer 
and call 


the process 
task. 
When 
the process 


task 
finishes, 
it can call the output 


task; the output 
task can finish with 
the buffer 
and return. 
When control 


returns 
to 
the 
input 
task, 
system 


processing 
for 
that 
buffer 
is com- 


plete. 
Another 
method 
is to have a 


polling 
task 
occasionally 
check 
if 


buffers 
are ready to be sent to other 


tasks. 
Both methods 
are inefficient 


and 
rigid, 
requiring 
that 
each task 


finish processing 
data in each buffer 


before 
another 
task can run. 


With 
an 
operating 
system, 
the 


buffers 
can be sent from task to task 
through 
"mailboxes" 
-places 


where 
tasks 
can 
send 
or 
receive 
data. 
(See Fig 6.) Task 
A sends 
a 


message (segment) 
to mailbox 
I and 


specifies 
mailbox 
2 
as 
a 
return 


mailbox. 
Task 
A then 
waits 
for a 
return 
message at mailbox 
2. Task B 


receives the message (segment) 
from 
mailbox 
I, 
then 
sends 
a 
return 


message 
with 
status 
to mailbox 
2. 


Task A receives the return 
message, 
which contains 
task 


B status, 
and synchronizes 
the two tasks. 


In general, 
each task obtains 
a segment, 
modifies 
its 


contents, 
sends the segment 
to the next task, 
and waits 


for another 
segment. 
The input task first gets a segment 


using "create 
segment." 
When 
the segment 
is full, the 


input 
task uses the kernel 
call "send 
message" 
to send 
the segment 
to mailbox 
A. The process 
task 
uses the 
"receive 
message" 
system call to wait at mailbox 
A for 


the segment. 
The process task receives the segment, 
pro- 
cesses the data, 
puts the new data 
in the segment, 
and 


sends the segment 
to mailbox 
B. The process 
task then 
waits at mailbox 
A for the next segment 
from the input 


task. The output 
task takes the segment 
from mailbox 
B 


Dynamically 
allocates 
area 
of memory 
of specified 
length 
in 16·byte 
paragraph 
units up to 64k-byte 
maximum 
leg, 


for use as buffer). 
Returns 
location 
token 
for segment 
allocated. 


Deallocates 
memory 
segment 
indicated 
by parameter 
token. 


Allows 
deletion 
of system 
data 
type 
value 
indicated 
by 
location 
token. 


Prevents 
deletion 
of system 
data 
type 
value 
indicated 
by 
location 
token. 


Deletes 
a mailbox; and returns 
its memory. 
If tasks 
are 
waiting 
for mailbox, 
they 
are awakened 
lie, their 
state 
is 
made 
ready) 
with 
appropriate 
exception 
condition. 
If 
messages 
are waiting 
for tasks, 
they 
are discarded. 


Sends 
message 
segment 
to mailbox. 


Task 
is ready 
to receive 
message 
at mailbox. 
Task 
is 
placed 
on mailbox 
task 
queue. 
Task 
can wait 
for 
response 
indefinitely, 
wait 
(generally 
10 
ms) units, 
or 
not wait. 
When 
complete, 
primitive 
returns 
to task 
the 
location 
token 
of message 
segment 
received. 


Creates 
region data 
type 
value, 
specifying 
queuing 
discipline. 
Returns 
token 
for region. 


Deletes 
region 
if the region 
is not in use. 


Gains control 
of region if region immediately 
available, 


but does not wait 
if not available. 


Links new 
primitive 
with 
kernel. 


Gives 
system 
type 
code 
of a system 
data 
type. 


control 
hardware, 
or mass storage. 
In this general 
pur- 


pose 
system, 
input, 
process, 
and 
output 
are the only 


functions, 
or lasks, 
that make up the system. 


Buffer mlnBgement 
Assume 
input 
data 
will be placed 
into 
128-byte buffers 
by the 
input 
task. 
Without 
help 
from 
the 
operating 


system, 
the buffers 
must 
be prelocated 
in RAM. Soft- 


ware 
is needed 
to manage 
the buffers, 
which 
must be 


given to the tasks 
in the correct 
sequence 
and returned 


for reuse when empty. 
If the buffers 
are too small, or if 


RAM is moved, 
the software 
must handle 
these changes. 


If an operating 
system 
or OSP is used, 
the locations 
and sizes of RAM are made 
known 
to the kernel during 


system initialization. 
The input task 


requests 
each 
buffer, 
or 
memory 


segment, 
from the kernel by making 


the kernel 
system 
call "create 
seg- 


ment" 
with 
128 bytes. 
If a larger 


buffer 
is needed, 
the create segment 


call needs a larger value for the size 
parameter. 
When 
the buffer 
is full, 


the input 
task gives the segment 
to 
the process 
task. When the buffer 
is 


no longer needed, 
it can be returned 


to 
the 
system 
memory 
pool 
by a 


"delete 
segment" 
system 
call. 


Because 
the 
kernel 
dynamically 


manages 
memory 
allocation 
and 


buffer 
access, 
no 
additional 
code 


for these functions 
is necessary. 


Additional 
primitives 
supported 
by 
the iRMX 
86 
nucleus 


CATALOGING 
SYSTEM 


OATA 
TYPES 


CATALOG 
OBJECT 


NEW 
SYSTEM 


DATA 
TYPES 


CREATE 
EXTENSION 


DELETE 
COMPOSITE 


INSPECT 
COMPOSITE 


SEMAPHORES 
CREATE 
SEMAPHORE 


DELETE 
SEMAPHORE 


SEND 
UNITS 


RECEIVE 
UNITS 


OTHER 
PRIMITIVES 
GET PRIORITY 


FO RCE DELETE 


GET SIZE 


ADDITIONAL 
JOB 
PRIMITIVES 
OFFSPRING 


SET POOL 
MINIMUM 


DELETE 
JOB 


Catalogs 
system 
data type token under name given 
by task in job partition 
directory. 


Removes name and token from job partition 
directory. 


Notifies 
kernel of new system 
data type code for 
new system 
data type. 


Removes system 
data type code and deletes all 


composite 
system 
data types with 
that system 
data 
type code. 


Creates 
new system 
data type from 
list of current 


system 
data types and system 
data type code 
received 
from create extension. 


Deletes new system 
data type. 


Gives list of system 
data types 
that form new 


system 
data type. 


Changes 
list of system 
data types 
that form new 


system 
data type. 


Creates semaphore 
system 
data type. 


Deletes semaphore 
system 
data type. 


Task adds a number of units 
to semaphore. 


Task asks for a number of units from 
semaphore. 
Task can wait for response 
indefinately, 
wait 


(generally 
10 ms), or not wait. 


appear, 
an error 
routine 
can 
alert 


the system operator 
that processing 


has stopped. 


The mailbox 
method 
has several 


advantages 
over 
synchronization 


algorithms 
and 
polling 
tasks. 
The 


entire process is synchronized 
by the 


availability 
of 
data 
in 
segments, 


eliminating 
the need for algorithms 


and 
extra 
code; 
the 
same 
process 


applies 
whether 
the tasks operate 
at 


the same or different 
speeds. 
Also, 


burst 
input 
or output 
rates 
can 
be 


handled 
by adding 
buffers. 
For in- 


stance, 
if too much data arrives 
for 


the process or oU,tput tasks.to 
handle 


immediately, 
the 
input 
task 
fills 


multiple 
buffers 
and passes them to 


mailbox 
A, The process 
task 
takes 


each 
segment 
in turn. 
After 
pro- 


cessing 
is completed, 
the segments 


are all sent to mailbox 
C, and the 


process 
waits 
for the next burst 
of 


data. 
The 
only 
interfaces 
between 


the 
tasks 
are 
mailboxes 
and 
seg- 


ments, 
so tasks 
can 
be easily 
re- 


placed 
or added 
to the 
processing 


loop; 
the 
same 
scheme 
works 
for 


larger or smaller 
segments, 


Tasks and task scheduling 
Tasks 
are 
independent 
bodies 
of 


executing 
code, 
initialized 
and 


sched uled by the kernel. 
Therefore, 


tasks must have iRMX 86 parameters 
like 
priority, 
initial 
memory 


resources, 
entry 
address, 
and other 


iRMX 
86 
data. 
A 
task 
is 
like 
an 


expanded 
subroutine 
managed 
by 


an 
operating 
system. 
The 
actual 


application 
code is written 
much the 


same 
as it is without 
an operating 


system 
except 
that 
requests 
are 


made using kernel calls. 


Even 
though 
the system's 
multi- 


ple independent 
tasks appear 
to run 


simultaneously, 
only 
one 
task 


actually 
runs 
at 
one 
time. 
Some 


method 
of scheduling 
is needed 
to 


decide which task receives control 
of 


the 
system 
processor; 
this 
sched- 


uling depends 
on the task 
priority. 
Since data 
coming 


into a system must not be missed, the input task has the 
highest priority. 
Data going out of the system are next in 


importance, 
so the output 
task has second 
priority; 
the 


sequential 
process 
task 
has 
the 
lowest 
priority, 
The 


scheduling 
algorithm 
is simple-the 
highest priority 
task 


that 
is ready 
to run will get control 
of the processor. 


This is an example 
of preemptive 
priority. 
In this case, 


ready to run means that a task is complete-it 
has a seg- 


ment to fill and data coming in (input task), data to pro- 
cess (process 
task), 
or data to output 
(output 
task). 
For 


instance, 
if input 
data 
arrives 
when the process 
task is 


running 
and the input task has a buffer 
waiting for data, 


,the input 
task will preempt 
the process 
task to receive 


Gives priority 
level of task. 


Deletes system 
data type even if disabled delete has 
been called for system 
data type. 


Gives byte size of memory 
segme!1t. 


Gives memory 
pool attributes 
of job partition, 
including 
pool minimum, 
poot maximum, 
initial size, 
number of bytes used, and number of bytes 
available. 


Changes pool minimum 
for job partition. 


Deletes job partition 
and returns its memory 
to parent 
job partition. 
. 


and outputs 
the data. 
The output 
task has two choices: 
it can either 
delete 
the segment, 
letting 
the input 
task 


create 
more 
segments, 
or it can send 
the 
segment 
to 


mailbox 
C. After 
sending 
or deleting 
the segment, 
the 


output 
task 
waits 
at mailbox 
B for the next 
segment 


from 
the process 
task. 
If the output 
task sent the seg- 


ment 
to mailbox 
C, the input 
task segments 
from 
the 


output 
task, 
synchronizing 
the input task with the out- 


put 
task. 
If the output 
task 
deleted 
the segment, 
the 
input 
task 
creates 
a new segment 
and 
waits 
for input 
data. 
The 
entire 
process 
runs 
continuously, 
synchro- 
nized 
by 
mailboxes 
and 
segment 
availability. 
Addi- 


tionally, 
the 
tasks 
can 
elect 
to 
wait 
for 
a specified 


amount 
of 
time 
at 
mailboxes, 
and 
if 
no 
segments 
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Fig 2 
110130 firmware component performs clock and 


interrupt control functions, and supplies operating system 
primitives. 


the data. 
If the input 
task is not running 
and the hard- 


ware 
driven 
by 
the 
output 
task 
is ready 
to 
output 


another 
data 
value, 
the output 
task will receive control 


of the processor. 


Since the operating 
system schedules 
the tasks, 
each 


task is designed 
as though 
it has sole control 
of the pro- 


cessor. Tasks make system calls such as receive message, 
which 
may 
cause 
another 
task 
to 
run 
because 
no 


message 
is waiting. 
In addition, 
interrupts 
will likely 


cause a different 
task to run. 
The kernel 
can schedule 


the 
tasks 
because 
only 
interrupts 
or system 
calls can 


cause a higher 
priority 
task to become 
ready, 
and both 


of these are handled 
by the kernel. 
Thus 
any time an 


interrupt 
occurs or a system call is made, the kernel runs 


the 
highest 
priority 
task 
that 
is ready. 
The 
tasks 
are 


written 
without 
any code 
to manage 
scheduling. 
The 


kernel 
scheduling 
is general 
purpose, 
so adding 
new 


tasks 
to 
the 
system 
does 
not 
require 
modifying 
the 


,APX 86110 


OR 
,APX 88/10 


scheduling 
functions. 
A system 
with 
work 
balanced 


among 
the 
tasks 
runs 
as 
though 
all 
tasks 
perform 
simultaneously. 


The net result 
of task scheduling 
is that 
the system 


runs as fast as it can. When data corne in, the input task 
will always get control 
of the processor. 
The output 
task 


will execute whenever 
it has data to send and the input 


task is not running. 
The process 
task will run whenever 


it has data and no other tasks are running. 
Also, tuning 


the system is easier with the standardized 
mailbox 
inter- 


faces: slower tasks can be easily removed 
and replaced 


with 
faster 
tasks, 
and 
remaining 
tasks 
will 
nN 
be 


affected. 


In a multitasking 
system, 
multiple 
independent 
tasks 


execute 
concurrently. 
Buffer 
transfers 
occur 
through 


mailboxes 
rather 
than 
through 
a direct 
interface 
to 


tasks, 
and system 
functions 
not related 
to the primary 


data processing 
functions 
can be handled 
by other tasks. 


For example, 
a supervisory 
task that monitors 
a system 


console for operator 
requests 
can be added to the system 


at a lower priority 
than the process task. No changes 
to 


any scheduling 
algorithm 
would be required. 


Interrupt 
management 
The iRMX 86 kernel and the asp provide 
two classes of 


interrupt 
management: 
interrupt 
handlers 
and interrupt 


tasks. 
An interrupt 
handler 
is a short 
procedure 
whose 


only function 
is to respond 
to the interrupt 
as quickly as 


possible. 
All interrupts 
become 
disabled 
in order 
to let 


the 
interrupt 
handler 
execute 
at top 
speed. 
Interrupt 


handlers 
can 
make 
only 
a few system 
calls. 
In the 
sample 
system, 
the interrupt 
procedure 
receives 
a data 
value, 
places 
it in a buffer, 
and 
returns. 
When 
the 


buffer is full, the interrupt 
handler 
notifies 
the interrupt 


task. 
Typical 
response 
time for an 8-MHz 
iAPX 86 pro- 
cessor, 
from the time an interrupt 
occurs until the inter- 


rupt handler 
gets control 
is 30 to 50/,s. 
In the unlikely 


event of a worst-case 
time, response time is about 
160 /'s. 


Higher priority 
interrupts 
are enabled 
when an inter- 


rupt handler 
gets control, 
is 30 to 50 /'s. In the unlikely 


task uses a mailbox 
to pass the full buffer 
on to the next 


task. 
Since 
both 
interrupts 
and 
tasks 
have 
priorities 


assigned 
to them, 
the kernel 
uses the task 
priority 
to 
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Fig 3 
iRMX16 hardware requirements. Operating system processor fits into basic hardware system 


for iRMX16 and brings with it functions of kernel memory, 
8259A programmable interrupt controller, 
and 8253 programmable in:errupt timer. 
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Fig 4 
Basic hardware 
system with iAPX OSP. osp replaces 
kernel code, 
programmable 
interrupt 


controller, 
and programmable 
interval 
timer. 


determine 
if interrupts 
should 
be disabled 
or enabled. 
If 


the task priority 
is higher than an interrupt 
priority, 
that 


interrupt 
is disabled 
while the task is running. 
A priority 


level can be given to a task that 
disables 
all, some, 
or 


none of the interrupts: 
ie, defining 
a task that is more 


important 
than 
all interrupts 
(initialization 
task), 
more 


important 
than some interrupts 
(input task), 
or less im- 


portant 
than all interrupts 
(processing 
task). 


Multiprogramming 
System parameters 
in a component 
system are normally 


well defined: 
RAM locations 
are fixed, 
code addresses 


are 
known, 
and 
address 
and 
110 ports 
are 
specified. 
Application 
code usually 
depends 
on these parameters. 
If the system 
changes, 
substantial 
alterations 
are often 


needed 
in the application 
code. 
However, 
if an iRMX 86 


operating 
system 
is used, 
the kernel 
is made 
aware 
of 


system 
resources 
during 
system 
configuration. 
System 


configuration 
assigns these resources 
to "jobs." 


Jobs 
do not 
do work 
but instead 
serve as resource 


boundaries, 
containing 
tasks 
that 
accomplish 
system 


functions. 
Many 
component 
applications 
systems, 
including 
the sample 
system, will have only one job. All 


system 
resources 
are given to the job and all tasks are 


contained 
there. 
When the system is initialized, 
the job 


is created 
and 
control 
is passed 
to the 
first 
task 
in 


the job. 


Fig 5 
General 
purpose 
system consists 
of 3 basic functions. 


Application 
code receives data, 
places data in buffer, 
tben 


processes 
it. Processed 
data are sent to interrupt 
driven 


output 
devices. 


Multiprogramming 
occurs when a system has two or 


more 
jobs. 
The 
system 
boundaries 
provided 
by jobs 


confirie 
errors 
and 
define 
limits 
for 
system 
resources 


such as memory. 
These 
boundaries 
limit the effect 
of 


one job on another. 
For instance, 
the system debugger 
is 


a separate 
job. 
During 
development, 
the sample 
pro- 


cessing 
system 
would 
look 
like Fig 7. After 
develop- 


ment, 
the debugger 
would be removed, 
leaving only the 


application 
system. The job environment 
of the process- 


ing system 
IS not affected 
by adding 
or removing 
the 


debugger. 
The overall system will, of course, 
be affected 


Fig 6 
Mailboxes 
allow intertask 
communication 
by 


providing 
places to send and receive messages 
(a). 


Syncbronization 
is easy since tasks can poll a mailbox 
and 


wait for messages. 
Mailboxes 
also form Interfaces 
between 


tasks in application 
system (b) so tasks can be easily added 


or removed 
without 
~banging code. 


because 
removing 
the debugger 
will 
cause 
more 
system 
resources 
to be 


available 
for other jobs. 


The 
jobs, 
tasks, 
segments, 
and 


mailboxes 
are part of a large set of 


system 
data 
types 
which 
are 
data 


structures 
managed 
by the operating 


system, System data types are manip- 
ulated 
only 
through 
system 
calls, 
which enforce 
the rules that govern 


their 
use. 
Together 
system 
data 


types and system calls form the appli- 
cation 
interface 
to 
the 
operating 


system. 
This interface 
provides 
not 


.only 
a 
good 
boundary 
for 
error 


detection 
and debugging, 
but also common 
architecture 
that can be carried 
from application 
to application. 


Fig 7 
Job structure for development provides distinct boundaries so tbat a 


debugger <a)or otber piece of development software can be used during system 
development and later removed witbout disturbing application job (b)• 


Debugging 
The iRMx 86 operating 
system has a debugger 
that inter- 


prets and uses system data types, and manipulates 
them 


to control 
the system. 
For example, 
the processing 
flow 


in the 
sample 
system 
can 
be halted 
by the 
debugger 


when a segment is sent to mailbox 
A. Data flow through 


the system can be traced by halting 
or breakpointing 
the 


system as the segment 
goes from mailbox 
to mailbox. 


Debugging 
is further 
aided by the modularity 
of the 


tasks 
and jobs. 
Modules 
limit error 
effects; 
the inter- 


faces 
between 
the 
modules 
are 
well defined; 
and 
the 


modules 
are 
easily 
inserted 
or removed. 
A standard 


system 
debugger 
can 
be 
used 
for 
all 
applications, 


avoiding 
the need to develop 
specific diagnostic 
tools. 


Conclusion 
Multiprogramming 
and multitasking 
promote 
applica- 


tion 
code 
modularity, 
allowing 
applications 
to 
be 


created 
by adding 
new functions 
to old software. 
The 


same scheduling 
and kernel interfaces 
work for systems 


with only a few tasks, 
or systems with many tasks per- 


forming 
multiple 
processes. 
An entirely new process can 


be added 
to the example 
b5' adding 
more 
tasks. 
If the 


new and existing processes 
have nothing 
in common, 
the 


new process 
can be in a different 
job. 
If both processes 


can share general purpose 
tasks, such as output, 
the new 


process 
can 
be in the 
same job 
and 
use the mailbox 


interfaces 
to send 
data 
to one output 
task. 
If system 


designers 
are careful, 
they 
can 
design 
systems 
whose 


functions 
can 
be added 
in the 
field. 
Thus, 
expensive 


custom 
software 
will not have to be rewritten 
for each 


new application. 


Users with a wide range of applications 
will find that 
this 
approach 
allows 
them 
to 
implement 
a 
corres- 
ponding 
range of capabilities, 
expanding 
an osp based 
system up to a high level human 
interface. 
A complete 
iRMX 
86 operating 
system 
includes 
extensive 
I/O 


capabilities, 
a 
debugger, 
an 
application 
loader, 
a 


bootstrap 
loader, 
and integrated 
user console 
functions. 


Such a system can perform 
general 
purpose 
processing 


and 
still 
provide 
all 
iRMX 
86 
facilities. 
With 
these 


features, 
one operating 
system can be used for current 


projects 
and expanded 
for future ones, minimizing 
soft- 


ware learning 
curves for new applications. 
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A PRIMER ON 
MAGNETIC BUBBLE MEMORY 


Magnetic 
bubble 
memory 
is a solid-state 
technology 
with high reliability, 
ruggedness, 
small size, light weight, and limited 
power dissipation. 
It has applications 
in telecommunications, 
data acquisition, 
industrial 
control, 
terminals, 
and small busi- 


ness computers. 
Yet many potential 
users remain 
unsure 
of the nature 
of a bubble 
memory. 
This primer 
is intended 
to 


introduce 
these users to the technology. 


A magnetic 
bubble memory stores data in the form of cylindrical 
magnetic domains 
in a thin film of magnetic 
material. 
The 
presence ofa domain(a 
bubble) is interpreted 
asa binary I, and absence of a domain 
is a O. Bubbles are created from electrical 
signals by a bubble generator 
within the memory, and reconverted 
to electrical signals by an internal detector. 
Externally 
the 
memory 
is TTL-compatible. 


An external 
rotating 
magnetic field propels these cylindrical 
domain 
bubbles through 
the film. Metallic patterns 
or chevrons 
deposited 
on the film steer the domains 
in the desired directions. 
Transfer 
rates, once started, are in the tens of thousands 
of 
bits per second, but because the data circulates past a pickup point at which it becomes available to the outside world, there is 
a latency averaging tens of milliseconds 
before data transfer can begin. In these respects, magnetic bubble memories are serial 
high-density 
storage 
devices like electromechanical 
disk memories. 
However, 
in a disk, the stored bits are stationary 
on a 
moving medium, 
whereas in the magnetic bubble memory 
the medium 
is stationary 
and the bits move. 


The principal 
advantage 
of magnetic 
bubble 
memories 
are their non-volatility-that 
is, if power fails, the stored data 
is 
retained. 
Products 
incorporating 
bubble memories 
therefore 
do not require 
battery 
backups. 
Magnetic 
bubble 
memories 
share this feature 
with read only memories 
(ROMs), 
erasable 
PROMs 
(EPROMS), 
and electrically 
erasable 
PROMs 
(E2PROMS). 
However, 
unlike any of these technologies, 
magnetic bubble memories can have data written into them at any 
time, at speeds comparable 
to those at which data is read. Furthermore, 
unlike disk memories, 
bubble memories 
are quiet 
and very reliable, because they have no moving parts. They are compact, 
and they dissipate 
very little power. Their support 
circuits are compatible 
with microprocessor 
systems. With a million or more bits per device, a bubble memory can store 16 to 
64 times the amount 
of data of alternative 
semiconductor 
memories, 
providing 
very high storage capability 
in a compact 
space. Bubble memory 
has a wide variety of applications, 
some of which are listed in Table I. 


inter 


Process control 
Oil exploration 


Aircraft 
navigation 
Data acquisition 


Cable television 
Portable 
instruments 


Word processors 
Office equipment 


Flight-line test equipment 
Automatic 
test equipment 


Magnetic 
domains 
are found in all kinds of magnetic materials-iron 
bars, the coating on magnetic tape, ferrite toroids (the 
most common 
form of computer 
memory in the 1960s). Each domain 
is a group of atoms with parallel magnetic orientations. 
When the material 
in bulk is unmagnetized, 
the domains 
are oriented 
at random 
in three dimensions. 
When the material 
is 
magnetically 
saturated, 
most of the domains 
have the same orientation. 
Magnetization 
to a level less than saturation 
orients 
some of the domains 
to a common 
direction, 
but leaves many of them randomly 
oriented. 
When a domain 
orientation 
changes, usually by imposing an external 
magnetic field, the domain 
itself does not physically move, but boundaries 
between 
domains 
that have different 
orientations 
move or disappear 
altogether. 


In an extremely 
thin film, less than 0.001 inch thick, the domain 
orientations 
may be constrained 
to two dimensions. 
In some 
kinds of material 
(orthoferrites 
and garnets), 
with proper crystallographic 
orientation, 
the <;Iomain orientations 
are always 
perpendicular 
to the film. When these materials 
are not in a magnetic 
field, some domains 
are oriented 
upward 
and some 
downward 
(north magnetic poles of some domains 
are on top of the film, and those of other domains 
are on the bottom). 
In 
these materials, 
the magnetic 
domains 
tend to be long and snakelike 
in the absence of an external 
field (Figure 
I). When a 
weak magnetic 
field is applied perpendicular 
to the film, the domains 
that are oriented 
opposite 
to the applied field become 
substantially 
narrower. 
As the applied 
field, called a bias field, is made stronger, 
the length continues 
to decrease, 
until it 
becomes approximately 
the same as the width. Each domain 
is now cylindrical, 
magnetized 
oppositely 
to the applied field, 


and immersed 
in a much larger domain 
that is magnetized 
in the same direction 
as the field. 
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These small domains 
are the bubbles, 
generally 
less than 3 micrometers 
(1/10,000 
inch) in diameter 
(Figure 2). When they 
are viewed from above, only the round shape isapparent, 
giving the domains the appearance 
of bubbles. If the bias field were to 
be made still stronger, 
all the bubbles would shrink and then disappear 
altogether; 
the entire film would be magnetized 
in the 
same direction as the bias field. The effect is reversible-that 
is, if the bias is removed, the domains 
return to a snakelike form. 
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Magnetic 
bubbles 
will move if they are in a magnetic 
field gradient. 
For instance, 
it will move from a region 
of lesser 
magnetic 
field strength 
to a region of greater 
strength. 
This is similar to the way a nail is pulled to the end of a bar magnet 
when it gets close the magnet. 


In a bubble 
memory 
a magnetic 
film pattern 
is overlaid 
on the layer of bubbles. 
When this layer is magnetized 
it pulls the 
bubbles 
to the points 
of greatest 
field strength 
(or poles) as in Figure 3. The bubbles 
could then be moved 
if the pattern 
elements 
were moved. 


A more easily controlled 
magnetic 
field is generated 
by two coils wrapped 
around 
the bubble layer and magnetic 
film pat- 
tern. With appropriate 
specification 
of the current 
in two coils positioned 
at right angles, the direction 
of the poles on the 
stationary 
elements 
can be changed 
in a controlled 
manner. 


Various 
shapes for these metallic 
patterns 
have been used by different 
manufacturers 
to control 
the movement 
of the 


bubbles. 
At Intel asymmetric 
chevrons 
are used (Figure 
3). 


In a magnetic 
bubble 
memory 
system, the bias field in which the bubbles 
exist is generated 
by a pair of permanent mag- 
nets. The substrate 
bearing 
the thin film and its bubbles 
is mounted 
between 
these magnets 
and is therefore 
continuously 
subject 
to the bias field. 


The rotating 
field that propels the bubbles 
through 
the film is generated 
by currents 
in two coils wrapped 
around 
the sub- 


strate at right angles to each other. These currents 
are generated 
by electronic 
circuits that are part of the magnetic 
bubble 
memory 
system. 
No mechanical 
motion 
is involved. 


If power fails, the circuits 
stop operating, 
the rotating 
field disappears, 
and the bubbles 
stop moving. 
But the bias field, 
generated 
by the permanent 
magnet, 
is not affected. Therefore 
the bubbles and the data that they represent 
are maintained 
in the film. When power is restored 
the data is again accesible. 


Bubble 
memories 
are produced 
in a process 
that 
resembles 
semiconductor 
manufacturing 
in many ways (Figure 
4). 


Manufacturing 
begins with a nonmagnetic 
garnet 
wafer on which a magnetic 
film is deposited, 
using conventional 
tech- 


niques. An ion implantation 
process alters the magnetization 
of the top surface of the film, discouraging 
the formation 
of 


abnormal 
bubbles 
with undesirable 
dynamic 
properties. 
Then 
nonmagnetic 
conductors, 
bubble-steering 
patterns 
of 


magnetic 
metal, 
insulation, 
passivation, 
and bonding 
pads are deposited 
in much the same way as successive 
layers on 


semiconductor 
integrated 
circuits. 
Patterns 
in each layer are defined 
photolithographically,just 
as with semiconductors. 


Magnetic 
bubble 
technology 
differs from semiconductor 
technology 
in the materials 
us~d and in the complexity 
of the 


process. 
Semiconductor 
circuits 
use eight or more layers of silicon doped 
with various 
materials 
that affect its electrical 
characteristics, 
compared 
to about 
three layers of essentially 
pure metallic and insulating 
material 
in bubble technology. 


These materials 
are chosen for their magnetic 
rather 
than their electrical 
properties. 
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The Intel7110 
magnetic 
bubble 
memory 
unit contains 
the bubble chip, the coils that generate 
the rotating 
field, two per- 
manent 
magnets 
for the bias field, and a magnetic 
shield that prevents 
disturbances 
by external 
fields and forms a return 
path for the bias field around 
the bubble 
chip (Figure 
5). 
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Data 
is stored 
in the bubble 
memory 
unit with a block-replicate 
architecture 
(Figure 
6). This architecture 
consists 
of a 


number 
of endless 
storage 
loops around 
which corresponding 
bits of successive 
pages continuously 
circulate, 
and two 
tracks, designated 
input and output, 
through 
which the controller 
writes and reads data in the storage 
loops. Exchange 
or 
replication 
of data between 
the tracks and the loops occurs in all loops simultaneously-the 
key idea in this architecture. 
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Figure 6. 
Block-Replicate 
Architecture 
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The seed bubble, at the beginning of the input track, is generated 
by an electric current pulse in a hairpin-shaped 
loop of con- 


ductive material. 
The pulse is strong enough to reverse the bias field locally and thus allow a bubble domain 
to be created. 


Once having been created, 
the seed bubble remains in existence as long as the external 
bias field is maintained. 


The seed circulates 
under a permalloy 
patch, driven by the rotating 
field that propagates 
bubbles elsewhere in the memory. 


This bubble 
is constrained 
to a kidney shape by interaction 
of the bias and rotating 
field with the metal patch (Figure 
7). 


The seed is split in two by a current 
pulse in the hairpin-shaped 
conductor. 
One of them remains under the patch as the seed, 


quickly regaining 
its original size; the other one. driven by the rotating 
field, is transferred 
to the input track section of the 


chip. The current 
pulse that splits the seed is generated 
to store a binary 1in the memory; to store a 0, the pulse is omitted, 
and 


no bubble is generated. 


DIRECTION 
OF CURRENT 
PULSE 


A seed bubble 
is maintained 
at one end of the input track. Bubbles corresponding 
to binary 
I's in the input word are split 
from the seed and propagate 
along the input track. When the input track contains exactly one page (64 bytes) then the bubbles 


exchange 
places with old bubbles previously 
circulating 
in the loops. This is accomplished 
by an operation 
called swapping. 


Thereafter 
the new bubbles circulate, 
while the old bubbles now in the track propagate 
to the end and are destroyed. 
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Transfer of data from the input track to a storage loop involves a swap, bringing the old data onto the input track for destruc- 
tion at the end ofthe line, while the new data takes its place in the loop. This is done whena current 
pulse in an associated 
con- 


ductor 
under the chevrons 
causes a bubble to jump from the input track to the storage loop and vice versa. The swap pulse is 
essentially 
rectangular, 
preserving 
the bubble without cutting it in two. 


~ 
STORAGE 
LOOP 
~ 


~~ooo~~~ 


REPLICATE 
GATE 
(B) 


To read the stored data, the circulating 
bubbles are replicated, 
one bubble or one unoccupied 
bubble site from each loop, onto 
the output 
track, after which they propagate 
to a bubble detector at its far end. After detection, 
these output 
bubbles are also 
destroyed. 
Meanwhile, 
the data in the loops continues 
to circulate, 
permitting 
a particular 
page to be read out repeatedly 
without 
regeneration, 
and protecting 
the stored data if power fails. 


Data is transferred 
from the storage loop to the output 
track by replication, 
continuing 
to circulate 
in the loop after having 
been read out. 


For replication, 
the bubble is propagated 
under a large element where it is stretched 
out. As it passes under a hairpin shaped 
conductor 
loop it is cut by a current 
pulse just as in bubble generation. 
The replicating current pulse waveshape has a high, narrow leading spike for cutting the original bubble in two, and a lower and 
wider trailing portion during which the new bubble moves under the output track. The entire pulse lasts about one-quarter 
of a 
cycle of the rotating field. In this manner the data in the storage loops is replicated onto the output track, and yet retained in the 
storage loops in case of a sudden power failure. 


Near the end of the output 
track is a bubble detector-essentially 
a magneto resistive bridge formed by interconnecting 
the 
permalloy chevrons to make a continuous 
electrical path of maximum 
length (Figure 9). As bubbles pass under the bridge, the 
resistance 
changes slightly, modulating 
the currents 
through 
the bridge and creating an output 
voltage of several millivolts. 


Bubbles are stretched at right angles to the direction of propagation 
by adding parallel rows of chevrons; these stretched bubbles 
generate 
larger output 
signals at the detector. 
Beyond the detector, 
the output 
track runs the bubbles into the guard rail and 
destroys them. 
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Figure 9. Bubble Detection 


The Intel magnetic bubble memory unit physically stores data in 320 storage loops, with capacities 
of 4,096 bits each. Of the 


320 loops, 272 are actually 
used (active) and 48 are spares (inactive); the boot loop records which loops are used. 


Some of the loops of an individual 
memory are set aside as spares. The decision as to which loops are to be used (active) and 
which are not to be used (inactive) 
is made after the memory 
unit has been assembled 
and is undergoing 
tests at the factory. 


The outcome 
of this decision is stored in an extra loop included 
in each memory chip, in the form of a 12 bit code for each 
"active" and "inactive" 
loop. 


Whenever power is turned on in the memory system, the system must be initialized before it can be used. Part of the initializa- 
tion process includes reading the contents 
of this extra loop, called the boot loop, and placing this information 
in a bootldop 
register in the formatter/ 
sense amplifier. 
From then on, as long as power is on, this register identifies the "active" loops for 
both reading and writing; "inactive" 
loops are ignored. The formatter 
does not attempt 
to store data in "inactive" 
loops, and 
the sense amplifier 
ignores any data that appears 
from these loops. 


Data is stored logically as 2,048 pages of5l2data 
bits each. 256 data bits plus l4error-eorrection 
check bits and 2 unused bits 
are stored in each half of the bubble chip. If automatic 
error correction 
is not used, these 16bits are available for data storage. 


Error detection 
and correction 
can be performed 
in the formatter/ 
sense amplifier, 
which includes a l4-bit cyclic redundancy 
code that corrects 
a single burst error of up to five bits in each 270-bit block including 
the code itself. These code bits are 
appended 
to the end of each 256-bit data block when writing into the cell, and checked when the block is read. The error cor- 
rection feature can be used or not at the user's discretion, 
by properly setting a register in the bubble memory controller 
chip. 
If it is not used, the loops occupied by the code bits become available 
for additional 
data. 
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Bubbles circulate 
at a rate of 50 kilohertz 
(the rotating 
field makes 50,000 complete 
revolutions 
per second). Average access 


time to the first bit ofthe first page is about 41 milliseconds-half 
the length of time required 
for a bubble to make one com- 
plete circuit of the loop, plus the time to shift a bubble along the length of the output 
track. 


The 320 active and spare loops are actually 
in four "quads" 
of 80 loops each (Figure 
10). This arrangement 
shortens 
the 
input and output tracks and thus reduces the read and write cycle times. The quads are separately 
addressable 
in pairs; in each 
pair the quads store odd-numbered 
and even-numbered 
bits of a word respectively. 
There are four seed bubbles 
and four 


input tracks, and four output 
tracks. The four output 
tracks share two detector 
bridges in such a way that there can never be 


bubbles from two tracks in a single detector simultaneously. 
By this means thefour 
streams of output bubbles are interleaved 
into two bit streams that are stored in two registers in the sense amplifier. 
The data in these registers is interleaved 
again into a 
single stream transmitted 
serially to the controller. 
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A magnetic 
bubble memory system consists of a controller 
and up to eight I-megabit 
magnetic 
bubble subsystems. 
A min- 
imum system has a controller 
and one subsystem. 
The subsystem 
comprises 
one magnetic 
bubble unit in which the data is 
actually 
stored, 
and the peripheral 
units listed in Table 2 and diagrammed 
in Figure 
II. These circuits are described 
later 
in this primer. 


7220-1 Bubble Memory 
Controller 
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Memory 


7110 Magnetic 
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7242 Formatter/Sense 
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7230 Current 
Pulse Generator 
7250 Coil Predriver 
7254 Drive Transistor 
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Five semiconductor 
integrated 
circuits are necessary to support 
each bubble chip. These components 
are described 
in some 
detail in the following paragraphs. 
Inaddition, 
ejlch bubble memory system requires a controller, 
a separate integrated 
circuit 
described 
later. 


Serial data to be stored in or read from the bubble memory passes through 
the FSA. The FSA keeps track of which loops in 
the bubble memory are spares, executes the error correction 
coding and decoding 
if it is implemented, 
and shifts data to the 
bubble memory 
input tracks or from the output 
tracks, amplifying 
the output 
signals from the memory. 
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The FSA has a chip-select 
input, which is normally 
grounded 
(permanently 
enabled). 
However, 
each FSA drives the chip- 
select input of other circuits associated 
with the same bubble chip, so they are all enabled at the proper time. 


All signals except those that control 
the rotating 
field originate 
in the CPG. This device is the source of a current 
pulse that 


cuts a new bubble from the seed bubble whenever 
the FSA has a binary 
I to be stored. 
Later, when this bubble reaches the 
loop in which it is to reside, the CPG issues the signal that swaps it with the bubble or non-bubble 
previously 
stored in that 
location of the loop. When data is to be read, the bubble is replicated on the output track by still another 
signal from the CPG. 


Four digital signals (positive and negative versions of both X and Y waveforms) 
are sent to the CPD from the controller 
with 


appropriate 
durations 
and phases to control the rotating field that moves the bubbles in the memory. 
The CPD combines and 


inverts these to form eight pulsed outputs that are amplified in a separate transisior 
package to drive the coils surrounding 
the 
bubble chip with a triangular 
current 
waveform. 


Photo 2. The Minimum Magnetic Bubble Memory System 


Including Controller 


The bubble memory controller 
is the interface between the memory system and the equipment 
it serves. It converts serial data 
to parallel 
and parallel data to serial, and generates 
all timing signals required 
by the other support 
circuits in the bubble 
memory 
system. It can control 
up to eight bubble subsystems, 
for a total of a megabyte 
of memory. 


Internal 
storage on the controller 
includes a first-in-first-out 
buffer with a capacity 
of 40 bytes. This buffer stores data to be 
sent serially to the FSA or just received from the FSA on one side, and data to or from the parallel bus served by the bubble 
memory 
on the other. It also serves as a speed matching 
device between the user at the' parallel bus and the FSA which must 
transfer data to and from the bubble device at exactly the rotating 
field ratio in each channnel. 


Bias field-a 
magnetic 
field perpendicular 
to a magnetic thin film that maintains 
conditions 
necessary to support 
formation 


of magnetic bubbles in the film. 


Boot loop-in 
a magnetic 
bubble memory 
with serial! parallel! serial architecture 
and redundant 
loops, a special loop con- 
taining information 
that identifies which loops are active and which are inactive, as determined 
by factory test. This loop also 
contains 
the information 
necessary to synchronize 
the bubble memory 
page locations 
with the controller 
after power up. 


Bubble, magnetic-a 
cylindrical magnetic domain 
in a thin film of orthoferrite 
or garnet. When viewed from above, the cylin- 


drical shape appears 
spherical, 
hence the name "bubble." 
A bubble represents 
a binary I in most magnetic bubble memories. 


Chevron-one 
of many possible shapes for a magnetic pattern deposited 
on a thin film to steer bubbles in a desired direction. 


Asymmetric 
chevrons 
are used in Intel memories. 


Domain, 
magnetic-a 
small region of a ferromagnetic 
substance 
that contains 
many similarly oriented 
atoms, 
so that the 


region as a whole is magnetized 
in that direction. 


E2PROM-an 
acronym 
for electrically 
erasable 
programmable 
read-only 
memory, 
which is a memory 
component 
that, 
though nominally 
read-only, can accept changes to any work stored in it by electrical means, but at substantially 
slower speed 
than that at which stored words are read. 


EPROM-an 
acronym 
for erasable 
programmable 
read-only 
memory, 
which isa memory component 
that, though nomin- 
ally read-only, 
can be completely 
erased, usually by exposure 
to ultraviolet 
light, and then reloaded 
with new information, 
but 
at substantially 
slower speed than that at which stored words are read. 


Ferrite-any 
of several compounds 
of iron, oxygen, and another 
metal, with magnetic 
properties 
that are useful in certain 


microwave 
applications 
and in computer 
memories. 


Garnet-a 
naturally 
occurring 
silicate mineral sometimes 
used in jewelry. Synthetic 
garnets with the same crystal structure 
can be made of oxides of iron and yttrium or one of the rare earths. Garnet 
is the preferred 
material 
for the thin magnetic film 


in a bubble memory. 


Input track-a 
series of magnetic metal patterns 
that control 
the movement 
of bubbles in a thin film, and thereby lead them 
from a bubble generator 
toward 
one or more storage patterns. 


Ion implantation-a 
process involving accelerators, 
similar to the machines 
used by nuclear physicists, for depositing 
dopants 
on and just below the surface of an electronic 
component; 
used to alter the physical properties 
of the material. 


Latency-a 
delay between a request to read or write data in a memory and the actual beginning 
of the operation, 
imposed by 
a requirement 
for the address 
to move physically (but not necessarily 
mechanically) 
to a point where the data transfer 
can 


take place. 
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Major 
loop-in 
a magnetic 
bubble 
memory, 
an endless loop containing 
a bubble generator, 
a bubble detector, 
and/ or a 
bubble annihilator, 
through 
which data is read or written, and which transfers 
bubbles to or from one or more minor loops 
(q.v.) in which they are stored. In some designs the majorloop 
is notendless, 
and all bubbles not transferred 
out of it collapse 
when they reach the end. In these cases the major loop becomes an input or output 
track (q.v.). 


Minor loop-in 
a magnetic bubble memory, an endless loop in which bubbles are stored, having been transferred 
into it from 
a major loop or input track (q.v.) and accessible by transfer 
into a major loop or output 
track (q.v.). 


Orthoferrite-one 
of several oxides of iron and either yttrium or a rare earth. The molecular 
structure 
is simpler than that of 
garnet (q. v.). Orthoferrites 
were the first materials 
used for the thin magnetic film in experimental 
bubble memories, 
but have 
yielded to garnets, 
which have more desirable 
properties-notably 
ease of preparation 
as thin films with the necessary 


magnetic 
characteristics. 


Output track-a 
series of magnetic metal patterns 
that control the movement 
of bubbles in a thin film, and thereby lead them 
from one or more storage patterns 
toward a bubble detector. 


PROM-acronym 
for programmable 
read-only 
memory-a 
read-only 
memory 
whose content 
is loaded by the user after 
delivery, as opposed 
to read-only 
memories whose content is fixed during manufacture. 
Once loaded, the data in a PROM 
is 
not alterable. 


Pseudo-random 
access-a 
property 
of some memory 
technologies 
in which the time of access to blOCks of stored data is 
largely (but not necessarily 
entirely) independent 
of the position 
of the block in the storage medium, 
but in which the time of 
access to bits, words or other entities depends 
on the position 
of that entity within the block. 


Random 
access-a 
property 
of some memory technologies 
in which the time of access to any stored bit, word, or other entity 
is wholly independent 
of that entity's position in the storage medium. 


Saturation-a 
state of magnetization 
of a material by a field such that, if the field is increased, 
the magnetization 
of the mater- 
ial does not increase and the magnetic flux density increases in proportion 
to the field (having increased much more rapidly in 
weaker fields). 


Serial access-a 
property 
of some memory 
technologies 
in which the time of access to any stored bit, word, or other entity 
depends 
strongly 
on that entity's position in the storage medium. 


Thin film-any 
film of material 
deposited 
on a s!1itable substrate 
to take advantage 
of the material's 
special properties 
when 
dispersed 
as a film. Thickness 
ranges usually from about 
10-9 to 10-6 meter, and occasionally 
to 10-5 meter or more, as in 
bubble memories. 


T-I bar-one 
of several possible shapes for a magnetic pattern deposited 
on a thin film to steer bubbles in a desired direction, 
consisting of shapes like the letter T and the letter I alternately 
along a track. This pattern was used extensively 
in early bubble 
memory designs, but is no longer generally employed. 
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iSBC™ 464 
64K BYTE EPROM EXPANSION 
BOARD 


• Compatible with Intel®2758, 2716 or 


2732/2732A erasable PROMs 


• Switch selectable base address on 4K 


byte boundaries for each memory bank 


• Assignable anywhere within a 1 


megabyte address space 


• EPROM components which are not 


enabled are placed in standby power 
mode 


• Requires a single + 5V power supply 


• Provides EPROM/ROM 
expansion of 


iSBC™ 80, iSBC™ 86 and iSBC™ 88 
systems via direct MULTIBUS 
interface 


The iSBC 464 is a member of Intel's complete line of iSBC memory and I/Oexpansion boards. The iSBC 464 board inter- 
faces directly to the iSBC 80, iSBC 86 or iSBC 88 single board computers via the MULTIBUS system bus, to expand 
system EPROM memory capacity. 


Memory Configuration 


The iSSC 464 board contains sixteen sockets which pro- 
vide a maximum of 64K bytes of memory expansion. The 
actual capacity 
of the board is determined 
by the type 
and quantity 
of EPROM components 
installed 
by the 
user. The board is compatible 
with three different 
sizes 
of Intel 
EPROM devices. These are the 1K byte 2758 
EPROM, the 2K byte 2716 EPROM, and the 4K byte 2732 
EPROM. 


Mode of Operation 
- 
The iSSC 464 board can operate in 
one of two modes: the 8 bit only mode or the Hi/8 bit 
mode. 
The 8 bit 
mode 
provides 
the 
most 
efficient 
memory configuration 
for systems 
handling 8 bit data. 
The 16/8 bit mode allows 16 bit words to be accessed by 
16 bit processors. 
In the 16/8 bit mode, 16 bit and 8 bit 
microprocessors 
may also access either the high order 
byte or the low order byte of a 16 bit word. The mode of 
operation 
is selected 
by placing 
two 
option 
jumper 
blocks in the appropriate 
sockets. 


Memory Banks - 
When used in the 8 bit mode, the iSSC 
464 board is organized 
into four banks (labeled A-D) of 
four sockets 
each. Depending 
on the type of memory 
components 
used, each bank may contain a maximum of 
4K, 8K or 16K bytes of memory. Unused memory sockets 
may be deselected 
by bank or individually 
in bank D. De- 
selecting a bank or individual 
socket frees that address 
space for use elsewhere 
in the system. In the 16/8 bit 
mode, banks A & Sand C & 0 are paired together to form 
two banks (labeled AS, CD) which are 16 bits wide. Each 
of these banks has four socket 
pairs. Sank AS may be 
deselected as a single unit. Socket pairs in bank'CD may 
be deselected 
individually. 
Thus, board configurations 
using fewer than 16 memory 
components 
do not fill 
memory address space with unused sockets. Selection/ 
deselect ion is accomplished 
by setting switches 
on the 
board. 


Memory Access Time - 
The iSSC 464 board operates 
with one of 15 switch 
selectable 
memory access times 
ranging 
from 
35 to 
1435 nanoseconds. 
This 
feature 
allows the board to be tailored to the performance of the 
installed components 
and the system CPU. 
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Memory Addresses 


Switch selectable options on the iSSC 464 board allow 
the board to be assigned anywhere within a 1 megabyte 
address space. In either operating mode, the base ad- 
dress of each memory bank may be set to any 4K byte 
boundary within a 64K byte memory page. There is one 
exception. If the 4K byte devices are used in the 16/8bit 
mode, then base addresses are restricted to 8K byte 
boundaries. If the board is used in a system with an 
address range greater than 64K bytes, memory on the 
iSSC 464 board may reside in one or two 64K byte mem- 
ory pages. Any two pages out of a possible 16 may be 
chosen by setting switches on the board. 


Standby Power Operation 


The iSSC 464 board takes advantage of the standby 
modes of the Intel 2758, 2716 and 2732. When they are 
not enabled, these components draw as little as 25% of 


their active level power with no degradation in access 
time. The iSSC 464 board is designed so that only two 
memory components are enabled during a read opera- 
tion. 


RAM Overlap 


Memory banks of the iSSC 464 board can be overlapped 
with the addresses of system RAM by setting on-board 
switches. The process of addressing a memory bank will 
drive the Inhibit RAM (INH1/) signal true. This signal is 
issued to the MULTISUS system bus in order to prevent 
any MULTISUS accessable RAM in the system from re- 
sponding to the current address. If an EPROM is ad- 
dressed 
which 
has its corresponding 
RAM overlap 


switch on. an access time of 15clock cycles is imposed. 
This allows overlapped dynamic RAM to refresh before 
the address on the MULTISUS is changed..The RAM 
overlap feature does not apply to RAM which is not on 
the MULTISUS system bus. 


Word Size 


8 bits or 16 and 8 bits 


Memory Size 


Sockets are provided for up to 16K bytes in 1K incre- 
ments or 32K bytes in 2K increments or 64K bytes in 4K 
increments 


Compatible 
Intel® Memory 


EPROM - 
2758 or 2716 or 2732 


INTERFACE - 
All 20 address. 16 data, and 6 control 


signals are TIL compatible and Intel MULTISUS com- 
patible 


Electrical 
Characteristics 


DC Power (max) 


VCC: +5V DC ±5% 
ICC: 1.1 amps without EPROMs 
ICC: 1.6 amps with (16)2716s or 2758s 
ICC: 1.3 amps with (16)2732s or 2732As 


Connectors 


Bus - 
86-pin double-sided PCedge connector with 0.40 


em (0.156 in.) contact centers 


Mating Connector - 
Viking 3KH43/9AMK12 or compati- 


ble connector 


Physical Characteristics 


Length - 
30.48 cm.(12 in.) 
Height - 
17.15 em (6.75 in.) 
Depth - 
1.27 em (0.5 in.) 
Weight - 
294 gm (10.5 oz) without EPROM 


Environment 


Operating Temperature - 
O·C to + 55·C 
Relative Humidity Limits - 
< 90% non-condensing 


Reference 
Manual 


9800643A - 
iSSC 464 Memory Expansion Soard Hard- 


ware Reference Manual (NOT SUPPLIED) 


Manuals may be ordered from any Intel sales represen- 
tative, distributor 
office or from Intel Literature Depart- 


ment. 3065 Sowers Avenue, Santa Clara, California 
95051. 


Part Number 


SSC 464 
Description 


64K EPROM Expansion Soard 
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iSBC® 428 UNIVERSAL 
SITE 
MEMORY EXPANSION 
BOARD 


• Supports EPROM, ROM, E2PROM, 
SRAM, IRAM and NVRAM 
• Sixteen 28 pin Universal sites 


• Assignable anywhere within a 16 
megabyte address space on 256K byte 
boundaries 


• Jumper selectable base address on 4K 
byte boundaries 


'. Provides support for Battery Backup/ 
Memory Protect 


The iSBC'" 428 Universal Site Board is a member of Intel's complete 
line of Memory and I/O Expansion 
boards. The 
iSBC 428 Universal 
Site Memory 
Expansion 
Board interfaces 
directly to the iSBC 80, iSBC 88, or iSBC 86 Single 
Board Computers 
via the MULTIBUS'" 
System Bus to expand system memory requirements, 
while system memory 
expansion 
requirements 
for iSBC 286 Single Board Computer 
can interface 
via either the MULTIBUS 
or the high 
speed iLBXTM Bus. 


Devices Supported 


Listed below are the current and future devices supported 
by the iSBC 428 board. 


Size 


Type 
512x8 
2Kx8 
4Kx8 
8Kx8 
16K x 8 
32Kx8 
64Kx8 
Comments 


EPROM 
- 
2716 
2732A 
2764 
27128 
27256 
X 
- 


ROM 
- 
X 
X 
X 
X 
X 
X 
- 


EEPROM 
- 
2817A 
X 
X 
X 
X 
- 
5V. Enhanced 


SRAM 
- 
X 
X 
X 
X 
X 
- 
NMOS 
& CMOS 


NVRAM 
- 
X 
X 
X 
- 
- 
- 
- 


IRAM 
- 
- 
- 
2186 
- 
X 
- 
- 


BANK A I BANK B 


I 
MEMORY 


ARRAY 


SIXTEEN 28-PIN 


UNIVERSAL SITES 


I 
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The iSBC 428 board contains sixteen 28 pin sockets. The 
actual capacity of the board is determined by the type and 
quantity of components 
installed by the user. The iSBC 
428 board is compatible with five different types and den- 
sities of devices: the 2K by 8 thru 64K by 8 EPROM/ROM 
devices, 2K by 8 thru 8K by 8 "Five Volt Only, Enhanced" 
E2PROM devices, 512 by 8 thru 16K by 8 NVRAM (Non- 
Volatile RAM) devices, 2K by 8 thru 32K by 8 SRAM de- 
vices, and 8K by 8 IRAM (Integrated RAM) devices. In ad- 
dition the board can be accessed by either the MULTIBUS 
System 
Bus or Intel's new high speed iLBX Bus. 


iLBX™ Bus 


The iSBC 428 board can be configured 
via jumpers 
to 
communicate 
with either the MULTIBUS interface or the 
iLBX Bus interface. Significant 
memory access time im- 
provements can be realized over the iLBX Bus interface 
(versus the MULTIBUS interface) due to its dedicated, un- 
arbitrated architecture. Additional information on the iLBX 
Bus is available 
in the iLBX Specification 
#144456-003. 


Memory Banks 


The sixteen sites on the iSBC 428 board are partitioned 
into two banks of 8 sites each. Within each bank the 8 
sites are further partitioned into 2 groups of 4 sites each. 
Each group of 4 sites is configurable 
to each of the six 
device types described above via a "Configurator". 
The 


"Configurator" 
is an arrangement 
of push-on jumpers 
which 
configures 
each of the four groups 
of 4 sites. 
Within each bank devices of the same density must re- 
Side and within 
each group devices 
of the same type 
must reside (i.e. SRAM or EPROM). 


Memory Addressing 


Addressing of the iSBC 428 board is by pages. There are 
64-256K pages which are jumper selectable. Each of the 
two banks are independently addressable and can reside 
in any page. Actual 
beginning 
and ending 
addresses 
within a page are a function of the actual device size and, 
as with the pages, are determined 
by jumpers. 
Because 
of the paging 
based memory 
addressing 
architecture 
more than one iSBC 428 board can be placed in a system. 


Mode of Operation 


The iSBC 428 board can operate 
in one of two modes: 


the 8 bit only mode or the 8/16 bit mode. The 8 bit mode 
provides the most efficient memory configuration 
for sys- 


tems handling 
8 bit data only. The 8/16 bit mode allows 
the iSBC 428 board to be compatible 
with systems em- 
ploying 8 bit and 16 bit masters. The mode of operation 
is selected by on board jumpers and is available for both 
MULTIBUS 
and iLBX Bus configurations. 


Memory Access 


The iSBC 428 board has jumper selectable access times 
which allows the board to be tailored to the performance 
of the particular 
devices which are installed in the iSBC 
428 board. The board can be configured 
via jumpers 
to 
accept devices with an access time range of 50 ns to 500 
ns with a granularity 
of 50 ns and results in a board ac- 
cess time from 225 ns to 775 ns. 


Interrupt 


The iSBC 428 board has the capability 
of generating 
an 
interrupt for the write and erase operations of E2pROMS. 
The interrupt can be configured 
in two ways: one, to sig- 
nal completion 
of the E2pROM write cycle, or two, allow 
polling 
by the system 
to determine 
the status 
of the 
E2pROM during the write programming 
time. 


Inhibits are provided on the iSBC 428 board to allow ROM 
to overlay RAM for bootstrapping or diagnostic operations. 
Each bank of the iSBC 428 board can be overlayed with 
the system 
RAM by jumpers 
provided 
on the board. 


Battery Backup 


The iSBC 428 board supports battery backup operation 
via a connector 
on the board. An auxiliary 
power bus is 
provided to allow separate power to the memory array for 
systems requiring battery backup. Selection of this aux- 
iliary power bus is made via jumpers 
on the board. 


An active-low TTL compatible 
Memory Protect signal is 
brought out on the auxiliary connector 
which, when as- 
serted, disables access to the memory array. This input 
is provided for the protection of Memory contents during 
system 
power-down 
sequences. 


Word Size 


8 or 8/16 bits 


Memory Size 


Sockets 
are provided 
for up-to sixteen 
28 pin devices 
which can provide 
up to 512K bytes of EPRoMIRoMI 
SRAM. 


Access Time 


Jumperable 
from 225 to 775 ns with a granularity of 50 ns 
and is equivalent 
for both MULTIBUS and the iLBX Bus. 


Power Requirements 
vee = 5 volts ± 5% 


Ice =2.0 amps, maximum, 
without any memory devices 
in the board. 


Physical Characteristics 


Length 
- 
30.48 cm (12 inches) 


Width -17.15 
cm (7.05 inches) 


Depth - 
1.27 cm (0.5 inches) 


Environment 


Operating 
Temperature 
- ooe to + 55°e 


Relative 
Humidity 
- 
90% non-condensing 


Reference Manual 


145696-001 
- 
iSBe 428 Hardware 
Reference 
Manual 
(NOT SUPPLIED) 


Additional Literature 


9800683-04 
- 
MULTIBUS 
Specification 


144456-001 
- 
The iLBX Specification 


Part Number 
Description 


SBe 428 
Universal 
Site Memory 
Expansion 
Board 


inter 


iSBC 341 
28-PIN MULTIMODULE 
EPROM 


• On-board memory expansion for iSBC 
86/05, i$BC 88/25, and iSBC 88/40 
microcomputers 


• Sockets for up to 64K bytes of expan- 
sion with Intel®27128 EPROMs 


• On-board expansion provides "no wait 
state" memory access with selected 
devices 


• Simple, reliable mechanical and 
electrical interface 


• Supports JEDEC 24/28-pin standard 
memory devices, including EPROMs, 
byte-wide RAMs, and E2PROMs 


The iSBC 341 28-pin MULTIMODULE 
EPROM board provides 
simple, 
low-cost 
expansion 
of the on-board 
EPROM capacity 
of the iSBC 86/05 Single 
Board Computer, 
the iSBC 88/25 Single 
Board Computer 
and the 
iSBC 88/40 Measurement 
and Control 
Computer. 
Four additional 
28-pin sockets 
support 
JEDEC 24/28-pin 
standard 
devices, 
including 
EPROMs, 
byte-wide 
static 
and pseudo-static 
RAMs. 


The MULTIMODULE 
expansion 
concept 
provides 
the optimum 
mechanism 
for incremental 
memory 
ex- 


pansion. 
Mounting 
directly 
on the microcomputer, 
the benefits 
include 
low cost, 
no additional 
power 
re- 
quirements 
beyond 
the memory 
devices, 
and higher 
performance 
than MUL TIBUS-based 
memory 
expan- 
sion. 


The iSBC 341 28-pin MULTIMODULE EPROM op- 
tion effectively 
doubles the number of sockets 


available for EPROMon the base microcomputer 
board on which it is mounted. The iSBC 341 board 
contains six 28-pin sockets. Two of the sockets 
have extended pins which mate with two of the 
sockets on the base board. Two of the EPROMs 
which would have been inserted in the base board 


are then reinserted in the iSBC 341 sockets. Addi- 
tional 'interface pins also connect 
chip select 


lines and power. The mechanical integrity of the 
assembly is assured with nylon hardware secur- 
ing the unit in two places. 


Through its unique interface, the iSBC 341 board 
can support 8 or 16-bit data paths. The data path 
width is determined by the base board - 
being 8 


bits for the iSBC 88/40 and iSBC 88/25 microcom- 
puters, and 8/16 bits for the iSBC 86/05 board. 


Word Size 


8 or 8/16 bits (determined by data path width of 
base board). 


Memory Size 


32K bytes with available technology (JEDECstan- 
dard defines device pin-out to 128K-bit devices). 


Device Size 
EPROM 
Max. iSBC 341 Capacity 


(Bytes) 
Type 
(Bytes) 


2Kx8 
2716 
8K 


4Kx8 
2732A 
16K 


8Kx8 
2764 
32K 
16Kx8 
27128 
64K 


Varies according 
to 
base board and memory 


device access time. Consult data sheet of base 
board for details. 


Memory Addressing 


Consult data sheet of base board for addressing 
data. 


POWER REQUIREMENTS 


Devices1 
Max. Current @ 5V :!: 5% 


2716 
420 mA 


2732A 
600 mA 


2764 
600 mA 


NOTE: 
1. Incremental power drawn from host board for four addition· 
al devices. 


Auxiliary 
Power 


There are no provisions for auxiliary power (bat- 
tery backup) on the iSBC 341 option. 


Physical 
Characteristics 


WIDTH - 
3.4 in. (8.64em) 


LENGTH - 
2.7 in. (6.86 em) 


HEIGHT - 
0.78 in. (1.98em))' 


WEIGHT - 
5 oz (141.5gm) 


·'ncludes 
height of mounted memory devices and base board. 


All necessary mounting hardware (nylon screws, 
spacers, nuts) is supplied with each kit. 


Environmental 
Characteristics 


OPERATINGTEMPERATURE- 
O°C to + 55°C 


RELATIVEHUMIDITY - 
to 90% (without conden- 


sation) 


All necessary documentation 
for the iSBC 341 


module is included in the CPU board Hardware 
Reference Manuals (NOT SUPPLIED) 


iSBC 86/05 - 
Order No. 143153-001 


iSBC 88/25 - 
Order No. 143825-001 


iSBC 88/40 - 
Order No. 124978-001 


Manuals may be ordered from any Intel sales rep- 
resentative, distributor office, or from Intel Litera- 
ture 
Department, 3065 Bowers Avenue, Santa 


Clara, California 95051. 


Part Number 


SBC 341 


Description 


28-Pin MULTIMODULE EPROM 


iSBC 300 or (pSBC 300*) 
32K·BYTE RAM EXPANSION 
MODULE 
iSBC 340 or (pSBC 340*) 
16K·BYTE EPROM EXPANSION 
MODULE 


• On-board memory expansion for iSBC 
86/12A Single Board Computer 


• iSBC 300 module provides 32K bytes of 
dual port dynamic RAM and plugs 
directly into the iSBC 86/12A board 


• iSBC 340 module provides sockets for 
up to 16K bytes of additional EPROM 
and plugs directly into the iSBC 86/12A 
board 


• On-board memory expansion 
eliminates 
MULTIBUS system bus 
latency and increases system 
throughput 


• Simple, reliable mechanical and 
electrical interconnection 


The iSBC 300 32K-byte RAM expansion module and the iSBC 340 16K-byte EPROM expansion module provide simple, 
low cost expansion of the memory complement available on the iSBC 86/12A single board computer. Each module 
utilized individually or together can double the iSBC 86/12A board's on-board RAM and EPROM memory capacity. The 
iSBC 300 32K-byte RAM expansion module and the iSBC 340 16K-byte EPROMexpansion module options for the iSBC 
86/12A board offer system designers a new level of flexibility 
in defining and implementing Intel<!lsingle board com- 
puter systems. These options allow the systems designer to double the memory complement of an iSBC 86/12A board 
with a minimum of system implications. 
Because they expand the memory configuration 
on-board, they can be ac- 
cessed as quickly as the existing iSBC 86/12A memory by eliminating the need for accessing the additional memory 
via the MULTIBUS system bus. With the iSBC 86/12A board mounted in the top slot of an iSBC 604 or iSBC 614 card- 
cage, sufficient 
clearance exists for mounting both the iSBC 300 and/or the iSBC 340 expansion module option(s). If 
the iSBC 86/12A board is inserted into some other slot, the combination of boards will physically (but not electrically) 
occupy two cardcage slots. InCremental power required by the options is minimal; for instance, only 305 mW is needed 
for the iSBC 300 RAM expansion module. 


The iSSG 300 module contains sixteen 16K-byte dynam- 
ic RAM devices, sockets for the Intel'" 8202A Dynamic 
computer. It expands the iSSG 86/12A board's on-board 
dual port RAM 
capacity from 32K bytes to 64K bytes. 


The iSSG 300 module contains sixteen 16K-byte dynam- 
ic RAM 
devices, sockets for the Intel'" 8202 Dynamic 
RAM 
Gontroller and memory interface latching. To in- 
stall the iSSG 300 modUle, the latches and controller 
from the iSSG 86/12A board are removed and inserted 
into the sockets on the iSSG 300 module. The add-on 
board is then mounted onto the iSSG 86/12A board. Pins 
extending 
from the controller's 
and latches' sockets 
mate with the devices' sockets underneath (see Figure 
1). Additional pins mate to supply power and other sig- 
nals to complete the electrical interface. The module is 
then secured at three additional points with nylon hard- 
ware to insure the mechanical security of the assembly. 


To complete the installation, two socketed PROMs are 
replaced on the iSSG 86/12A board with those supplied 
with the iSSG 300 kit. These are the on-board memory 
and MULTISUS address decode PROMs which allow the 
iSSG 86/12A board logic to recognize its expanded 
on-board memory complement. 


The iSSG 340 module expands the iSSG 86/12A Single 
Soard Gomputer's on-board EPROM capacity from 16K 
bytes to 32K bytes. It measures 3.3" by 2.8" and consists 
of a PG board with six 24-pin special sockets. Two of the 
sockets have extended pins which mate with two of the 
EPROM sockets on the iSSG 86/12A board. Two of the 
EPROMs which would have been inserted on the iSSG 
86/12A 
board are then 
reinserted 
in the iSSG 340 


module. Additional 
pins also mate for bringing 
chip 


selects for the remaining EPROMdevices (see Figure 2). 
The mechanical interface is similar to that used on the 
iSSG 300 RAM 
module and consists of two additional 


mounting holes and the necessary mounting hardware. 


The iSSG 340 module supports Intel@2732A EPROM. 
One section of the iSSG 86/12A on-board memory and 
MULTISUS address decode PROMs (the same decode 
PROMs mentioned for the iSSG 300 module) is already 
preprogrammed to support the iSSG 340 module with 
Intel@2732A EPROMs. This section is selected through 
the EPROM configuration switches on the iSSG 86/12A 
board. The iSSG 340 board can optionally be configured 
by the user to support Intel'" 2758 or 2761 EPROMs by 
programming new iSSG 86/12A decode PROMs to sup- 
port 
these 
devices. 
Necessary 
documentation 
and 


PROM map listings 
are in the iSSG 86/12A Hardware 


Reference Manual (order number 9803074-01). 


REPLACEMENT 


MEMORY 
ADDRESS 
DECODE 
PROMS 


(SUPPlI~D 
WITH 


i$BC 
300 OPTION) 


NYLON 
MOUNTING 
HARDWARE 


13 PLACES) 
(SUPPLIED 
WITH 
iSBC 
300 
OPTION) 


SPECIFICATIONS 


Word Size 
8 or 16 bits (16-bit data paths) 


Memory Size 
ISBC 300 Module - 
32,768 bytes of RAM 
ISBC 340 Module - 
16,384 bytes (max) of EPROM 


Access 
Time 
ISBC 300 Module - 
Read: 1 !,sec, write: 1.2 !'sec 
ISBC 340 Module 
- 
Standard 
EPROMs (450 nsec): 1 
!,sec, fast EPROMs (350 or 390 nsec): 800 nsec 


Interface 
The interface for the iSBC 300 and iSBC 340 module op- 
tions 
is designed 
only for Intel's 
iSBC 86/12A Single 
Board Computer. 


Memory Addressing 
On-board 
RAM 
CPU Access 
ISBC 86/12A board only (32K bytes) - 
00000-07FFFH. 
ISBC 86/12A board + ISBC 300 module (64K bytes) - 
OOOOO-OFFFFH. 
MUl TIBUS Access - 
Jumper selectable for any 8K- 
byte boundary, but not crossing a 128K-byte boundary. 


On-board EPROM 
ISBC 86/12A board only (16K-bytes 
max.) - 
FFOOO- 
FFFFFH (using 2758 EPROMs): FEOOO-FFFFFH(using 
2316E ROMs or 2716 EPROMs); and FCOOO-FFFFFH 
(using 2332A ROMs or 2732A EPROMs). 


ISBC 86/12A board + ISBC 340 module (32K bytes 
max) 
- 
FEOOO-FFFFFH 
(using 
2758 
EPROMs); 
FCOOO-FFFFFH 
(using 
2716 
EPROMs); 
F8000- 
FFFFFH (using 2732A EPROMs). 


On-board 
EPROM/ROM 
is 
not 
accessible 
via 
the 
MUL TIBUS interface. 


Auxiliary 
Power/Memory 
Protection 
The low power memory protection 
option 
included 
on 
the iSBC 86/12A boards supports 
the iSBC 300 RAM 
module. 


"Local Only" Memory Protection 
The 
iSBC 
86/12A 
Single 
Board 
Computer 
supports 
dedication 
of on-board 
RAM for on-board 
CPU access 
only in 8K, 16K, 24K, or 32K-byte segements. Installation 
of the iSBC 300 option allows protection of 16K, 32K, 48K, 
or 64K-byte segments. 


ISBC 300 
ISBC 340 


Width 
5.75" 
33" 


Length 
2.35" 
2.8" 


Height of iSSG 86/12A 
.718 
.718' 
plus mounted option 


Weight 
13 oz. 
5 oz. 


All 
necessary 
mounting 
hardware 
(nylon, 
screws. 


spacers, nuts) are supplied with each kit. 


iSBC 
340 
OPTION 


~ 


Voltage 
ISBC 300 
ISBC 340 


+5 ±5% 
1 mA 
120 mA' 


+12 ±5% 
24 mA 
- 


-12 ±5% 
1 mA 
- 


Environmental 
Characteristics 


Operating 
Temperature 
- 
0° to +55°C 


Relative 
Humidity 
- 
to 90% (without 
condensation) 


Reference Manuals 


All 
necessary 
documentation 
for 
the 
iSBC 
300 MUL TI- 


MODULE 
RAM and iSBC 
340 MUL TIMODULE 
EPROM/ 


ROM is included 
in the iSBC 86/12A 
Hardware 
Reference 


Manual; 
order 
#9803074-01. 
(NOT 
SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel sales representa- 


tive distributor 
office 
or from 
Intel Literature 
Department, 


3065 Bowers 
Avenue, 
Santa 
Clara, 
CA 95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SBC 300 


SBC 340 


32K byte 
MUL TIMODULE 
RAM 


16K byte MUL TIMODULE 
EPROM 


iSBC® 304128K 
BYTE RAM MULTIMODULE™ BOARD 
iSBC® 300A 32K BYTE RAM MULTIMODULE™ BOARD 


• iSBC®304 module provides 128K bytes 
of dual port RAM expansion for the 
iSBC®86/30 board 


• iSBC®300A module provides 32K bytes 
of dual port RAM expansion for the 
iSBC®86/14 board 


• Simple, reliable, mechanical and 
electrical interconnection 


• On-board memory expansion for the 
iSBC®86/30 and iSBC®86/14 Single 
Board Computers 


• On-board memory expansion 
eliminates MULTIBUS® system bus 
latency and increases system 
throughput 


The iSBC 304 and iSBC 300A RAM modules 
provide simple,low 
cost expansion 
of the memory compliment 
available 
on the iSBC 86/30 and iSBC 86/14 Single 
Board Computers, 
respectively. 
Each module 
doubles 
the Qn-board RAM memory 
capacity 
of the host 
board. The RAM MUL T1MODULE options 
for the host 


boards offer system 
designers 
a new level of flexibility 
in defining 
and implementing 
Intel single 
board 


computer 
systems. 
Because they expand the memory 
configuration 
on-board, 
they can be accessed 
as 
quickly 
as the existing 
host board memory 
by eliminating 
the need for accessing 
the additional 
memory 
via the MULTIBUS 
system 
bus. 


The 
lollowing 
are 
trademarks 
of Inlel 
Corporation 
and 
may 
be used 
only 
10 descrtbe 
Intel 
products: 
Intel, 
CREDIT, 
Index. 
InsHe, 
lntellec, 
library 
Manager. 
Megachassls, 


Micromap, 
MUl TIBUS, 
PROMPT, 
UPI. ~Scope, Promware, 
MeS, 
ICE, IAMX. 
ISeC, 
ISeX, 
MULTIMODULE 
and ICS 
Intel Corporation 
assumes 
no responSibility 
lor the use 01 any 


circUitry 
other 
than CUCUltry embodied 
in an Intel 
product 
No other 
CirCUli patent 
licenses 
are Implied. 


Each 
MUL TIMODULE 
contains 
dynamic 
RAM 


devices 
and sockets 
for the 
Intel 8203 dynamic 


RAM controller 
and memory interface 
latching. 
To 


install the module, the latches and controller 
from 


the host CPU board are removed and inserted 
into 


sockets 
of")the RAM MULTIMODULE. 
The module 


is then mounted 
onto the host board. Pins extend- 
ing from 
the controller 
and latch 
sockets 
mate 


with device sockets 
underneath 
(see Figure 1). Ad- 


ditional 
pins mate to supply other signals 
to com· 
plete the electrical 
interface. 


The module 
is then 
secured 
at three 
additional 


points with nylon hardware to ensure the mechani- 
cal security 
of the assembly. 


To complete 
the installation, 
one socketed 
PROM 


is replaced 
on the host CPU board with 
the one 


supplied 
with the MULTIMODULE 
kit. This is the 


MUL T1BUS address 
decode 
PROM which 
allows 


the host board logic to recognize 
its expanded 
on- 


board memory compliment. 


REPLACEMENT 
MEMORY 
ADDRESS 
DECODE 
PROM 


(SUPPLIED 
WITH 
iSBC' 


MUl 
T1MOOUlE'" 
OPTION) 


NYLON 
MOUNTING 


HARDWARE 
(3 PLACES) 


(SUPPLIED 
WITH 
iSBC' 


MUlTlMODUlP"' 
OPTION) 


intel 


Word Size 


8 or 16 bits (16-bit data paths) 


Memory Size 


iSBC" 304 Module 
- 
128K bytes RAM 


iSBC" 300A Module 
- 
32K bytes RAM 


Cycle Time 


iSBC" 304 - 
700 nsec (read); 700 nsec (write) 


iSBC" 300A - 
700 nsec (read); 700 nsec (write) 


Memory Addressing 


CPU ACCESS 


iSBC" 304 (with 
iSBC'" 86/30) - 
256K bytes (total 


capacity); 
0-3FFFFH 
(address 
range) 


iSBC" 300A (with 
iSBC'" 86/14) - 
64K bytes (total 


capacity); 
O-OFFFFH (address 
range) 


Jumper 
selectable 
for any 32K (8K) byte boundary, 


but not crossing 
a 256K (128K) byte boundary 
on 


the iSBC 86/30 (iSBC 86/14) host board. 


Interface 


The interfaces 
for the 
iSBC 304 and iSBC 300A 


module 
options 
are designed 
only 
for the 
iSBC 


86/30 and iSBC 86/14 host boards, respectively. 


Private Memory Allocation 


Segments 
of the combined 
host/MULTIMODULE 


RAM 
memory 
may 
be configured 
as a private 


resource, 
protected 
from 
MUL T1BUS system 
ac- 


cess. The amount of memory allocated 
as a private 


resource 
may be configured 
in increments 
of 25% 
of the total on-board 
memory 
ranging 
from 0% to 


100%. The iSBC 304 module 
mounted 
on the iSBC 


86/30 board, therefore, 
supports 
private allocation 


of 64K, 128K, 192K, or 256K bytes of RAM memory. 
The iSBC 300A module mounted 
on the iSBC 86/14 


board supports 
private allocation 
of 16K, 32K, 48K, 


or 64K bytes of RAM memory. 


Auxiliary Power 


The low power memory protection 
option 
included 


on the CPU host boards 
supports 
the RAM mod- 


ules. 


Physical Characteristics 


Width 
- 
2.4 in. (6.10 cm) 


Height 
- 
5.75 in. (14.61 cm) 


Depth" 
- 
.72 in. (1.83 cm) 


Weight 
- 
.13 oz. (59 g) 


Electrical Characteristics 


DC POWER 
REQUIREMENTS 


iSBC'" 304 
- 
640 ma at 
+ 5 volts 
incremental 


power 


iSBC'" 300A 
- 
256 ma at + 5 volts 
incremental 


power 


Environmental Characteristics 


Operating 
Temperature 
- 
O°C to 55°C 


Relative Humidity - 
to 90% (without 
condensation) 


Reference Manual 


All necessary 
documentation 
for the iSBC 304 and 


iSBC 300A MUL TIMODULE 
boards 
is included 
in 
the 
iSBC 86/14 and iSBC 86/30 Hardware 
Refer- 


ence Manual (NOT SUPPLIED). 


Manuals 
may be ordered 
from any Intel sales rep- 


resentative, 
distributor 
office 
or from 
Intel litera- 


ture Department, 
3065 Bowers Avenue, Santa Clara, 


CA 95051. 


Part Number 
Description 


SBC 304 
128K MULTIMODULE 
option 


for iSBC 86/30 board 


SBC 300A 
32K MULTIMODULE 
option 
for 
iSBC 86/14 board 


iSBC™ 303 
MULTIMODULE™ 
PARITY 


• Add-on parity option 
for iSBC 86/12A 
Single 
Board Computer 


• Supports 
32KB or 64KB (with iSBC 300 
MULTIMODULE 
RAM) on-board 
RAM 


• Byte parity with programmable 
odd/even 
detection/generation 


• Two LED error indicators 


• Two interrupt 
requests 
for error 
reporting 


• No degradation 
of memory 
performance 


• Memory diagnostic 
capability 


The iSBC 303 MULTI MODULE Parity option 
provides 
on-board 
parity support 
for the on-board 
RAM of the 


iSBC 86/12A Single 
Board Computer. 
Memory parity generation/detection 
is invaluable 
for those applica- 


tions 
in which 
execution 
of erroneous 
instructions 
or data must be prevented, 
as in critical 
process 
con- 


trol, 
medical 
and financial 
transaction 
systems. 
When used on single 
board computers 
in conjunction 


with 
MUL TIBUS®-based, 
parity-protected 
RAM expansion 
boards 
in large 
memory 
configurations, 
the 


iSBC 303 MUL TIMODULE 
Parity option 
provides 
consistent 
protection 
throughout 
all system 
RAM. 


The following 
are trademarks 
of Inlet 
CorporatIon 
and may be used only 
to descnbe 
Inlel 
products. 
CREDIT, 
Index, 
InSlte, 
Intellee, 
Library 
Manager, 
Megachassls, 
Mlcromap, 


MULTIBUS, 
PROMPT, 
UP1, ,.Scope. 
Promware, 
MeS, 
ICE, IRMX, iSSe, 
ISaX, 
MULTIMOOULE, 
ICS, lAPX 
and iMMX. 
Inlel Corporation 
assumes 
no responsibility 
lor the use of any 
cirCUItry other 
than circuitry 
embodied 
in an Intel product. 
No other circuit 
palent 
licenses 
ar~ implied. 


inter 


The iSBC 303 MUL TIMOOULE 
Parity 
option 
is a 


complete 
subsystem, 
providing 
all 
necessary 


logic 
and display 
to support 
the iSBC 86/12A on- 
board 
RAM. 
Operation 
of 
the 
iSBC 
303 option, 
once 
initialized, 
is transparent 
to the system, 
as 


the option 
causes no memory 
performance 
degra- 
dation. 
If an error 
is detected 
and interrupts 
are 
enabled, 
an interrupt 
request 
will be issued to the 


iSBC 86/12A board. Included 
on-board 
is the parity 
generator/checker 
and parity' memory 
RAM, the in- 
terrupt 
request 
logic, error display, 
command 
reg- 


ister and the necessary 
interface 
for address, data 
and control 
(inputs) 
and interrupt 
requests 
(out- 


puts) (See Figure 
1). The parity generator/checker 


is a 74S280 MSI device. 
The memory 
devices 
are 


four 
Intel<!J2118 
dynamic 
RAMs. 
Parity 
is 
generated/detected 
on a byte 
basis; 
for a 32KB 
RAM configuration, 
only 
two of the parity 
RAMs 


are used. When the iSBC 303 board is used in con- 
junction 
with 
the iSBC 300 32KB MULTIMOOULE 
RAM option 
(which 
provides 
a total 
of 64KB on- 
board RAM), all four parity RAMs are used. Odd or 
even 
parity 
may 
be 
programmatically 
selected 


through 
the command 
register. 
This feature 
also 


provides 
the 
ability 
to 
"force 
errors" 
to 
verify 


operation 
of the board. 


Error Reporting 


Two 
interrupt 
requests 
are provided: 
one which 


can be connected 
to the 
NMI input 
of the 
Intel 
8086 CPU, and another 
which 
can be wired to the 


Intel 8259A interrupt 
controller 
and/or Intel 8255A 
Programmable 
Peripheral 
Interface 
on the 
iSBC 


PFIN 
D 
NMIMASK 


86/12A 
board. 
The 
'NMI 
request' 
can 
be 
enabled/disabled 
via the command 
register 
or op- 


tionally 
with 
the NMIMASK 
signal 
which 
can be 
controlled 
by the 8255A PPI. Additionally, 
a power 


fail 
request 
signal 
originating 
from 
the 
system 
power supply 
can be "OR'ed" 
with the parity 
NMI 


request, 
allowing 
both signals 
to be issued 
to the 


8086 CPU. 


The error display 
logic 
contains 
two 
LEOs which 


indicate 
errors 
for high and low bytes. 
High and 
low byte error signals 
can also 
be connected 
to 
the 8255A, to read error status 
under program con- 


trol. The LEOs and error signals 
are controlled 
by 


the command 
register. 


Base-board Interface 


The address, 
control 
and data signals 
are gener- 


ated by the iSBC 86/12A RAM logic, 
and are con- 


nected 
to the iSBC 303 module 
through 
the sock- 


ets of the Intel 8202A RAM controller 
and the data 
latches 
(see Figure 
2). The other 
I/O signals 
to/ 


from 
the 
iSBC 303 board 
are brought 
out 
to an 


8-pin connector 
from which 
a cable assembly 
(not 


supplied) 
establishes 
connections 
to 
the 
iSBC 
86/12A board. 
Mechanical 
integrity 
is assured 
by 


three-point 
mounting 
with 
nylon 
hardware. 
The 
iSBC 86/12A and iSBC 303 boards can be mounted 
in the end slot of an Intel iSBC 604/614 cardcage. 
If 
mounted 
in 
other 
than 
the 
top 
slot, 
it 
will 


physically 
occupy 
two 
slots. 
The 
iSBC 
86/12A, 


300, 303 board combination 
will 
not fit in the top 
slot, 
and also 
occupies 
two 
cardcage 
positions 


when mounted. 


Ii 


" 
I 
., 
I 


~~/ 


NYLON 
MOUNTING 
HARDWARE 
13 PLACES) 
(SUPPLIED 
WITH 
ISSC 
303 OPTION) 


Programmatic Control 


The command 
register 
is a 4-bit, memory 
mapped 
register 
through 
which 
the operation 
of the iSBC 
303 module 
is controlled 
(see 
Figure 
3). Read/ 
write access 
to all bits is available 
through 
either 
location 
OH or 400H (jumper 
selectable). 
Initializa- 
tion software 
should 
enable the NMI interrupt 
and 
the 
maskable 
interrupt 
and 
LED, as required. 
It 
should 
also select 
odd or even parity 
generation 
(odd is recommended 
for detection 
of catastrophic 
RAM failure). 


Diagnostic Capability 


Operation 
of the iSBC 303 module 
and the integ- 
rity of the RAM can be checked 
with a diagnostic 
software 
routine 
which 
can 'force 
errors' 
in parity 
memory. 
This is accomplished 
by writing 
data in 
one parity 
mode (e.g. odd), toggling 
the odd/even 
bit and then reading 
data with the complementary 


parity 
mode (e.g. even). These reads should 
cause 


deteCtable 
errors and interrupts 
will be generated, 


verifying 
the 
error 
detecting 
and 
reporting 


capability. 


0- 
ODD PARITY 


1 - EVEN PARITY 


0- 
lED 
CLEAR 
1 - LED ENABLED 


0- 
INTR CLEAR 
1 - INTR 
ENABLED 


0- 
NMI CLEAR/MASK 
1 - NMI ENABLED 


Figure 3. iSBC™ 
303 Option 
Command/Status 
Register 


Word Size 


Byte parity on 8 and 16-bit words. 


Cycle Time 


Supports 
iSBC 86/12A memory 
cycle 
times 
with 
no additional 
wait states. 


Memory 
Capacity 


Supports 
32KB of iSBC 86/12A on-board 
RAM or 
64KB with 
iSBC 300 MULTIMODULE 
RAM option. 


Interface 


All signals 
TTL compatible. 


Pins 


Shells 
Reeled 
Loose 


AMP 
87456-4 
86491-3 
87045-2 


Berg 
65043-033 
47564 
47744 


Auxiliary 
Power/Memory 
Protection 


The auxiliary 
power (i.e. battery 
backup operation) 
and memory 
protection 
(i.e. write 
disable 
on out- 
of-limits 
power 
supply 
voltages) 
features 
of the 
iSBC 
86/12A 
Single 
Board 
Computer 
are 
sup- 
ported 
on the iSBC 303 module. 


Physical 
Characteristics 


Width 
- 
6.375 in. (16.2 cm) 


Height - 
Height of iSBC 86/12A board + iSBC 303 
module: 
0.718 in. (1.82 cm) 
Height 
of iSBC 86/12A board + iSBC 300 
module + iSBC 303 module: 
1.05 in. (2.66 cm) 


Depth - 
2.40 in. (6.1 cm) 


Weight 
- 
2.3 oz. (28.5 gm) 


All 
necessary 
mounting 
hardware 
(screws, 
nuts, 


spacers) 
are supplied 
with 
each kit. 


Electrical 
Characteristics 


605 mA max., + 5 VDC (± 5%) 


Environmental 
Characteristics 


Operating 
Temperature 
- 
O°C to + 55°C 


Relative 
Humidity 
- 
To 90% (without 
condensa- 
tion) 


Reference 
Manual (Not Supplied) 


All 
necessary 
documentation 
for 
the 
iSBC 
303 
MULTIMODULE 
Parity option 
is contained 
in the 
iSBC 
86/12A 
Single 
Board 
Computer 
Hardware 
Reference 
Manual; order #9803074-02. 


Manuals 
may be ordered 
from any Intel sales rep- 
resentative, 
distributor 
office 
or from 
Intel Litera- 
ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 
Clara, CA 95051. 


Part Number 


SBC 303 


Description 


MULTIMODULE 
Parity 


iSBC™ 302 
8K·BYTE MULTIMODULE™ 
RAM 


• Expands on-board memory of the 


iSBC™ 86/05 and iSBC™ 88/25 Single 
Board Computers 


• Uses four Intel®2168 static RAMs 


• Single + 5V supply 


• On-board memory expansion 
eliminates system bus latency and 
increases system throughput 
, 


• Reliable mechanical and electrical 


interconnection 


The Intel iSBC 302 8K-Byte 
MULTI MODULE RAM provides 
simple, 
low-cost 
expansion 
to double 
the RAM 


capacity 
on the iSBC 86/05 Single 
Board Computer 
to 16K bytes or increase 
RAM capacity 
on the iSBC 
88/25 Single 
Board Computer 
to 12K bytes. This offers 
system 
designers 
a new level of flexibility 
in im- 
plementing 
system 
memory. 
Because 
the MULTIMODULE 
memory 
is configured 
on-board, 
it can be ac- 


cessed 
as quickly 
as the standard 
on-board 
iSBC 86/05 or iSBC 88/25 memory, eliminating 
the need for ac- 


cessing 
additional 
memory via the MULTIBUS system 
bus. As a result, the iSBC 302 board provides 
a high- 


speed, cost-effective 
solution 
for systems 
requiring 
incremental 
RAM expansion. 


The iSBC 302 board measures 
2.60" by 2.30" and 
mounts 
above the RAM area on the iSBC 86/05 or 


iSBC 88/25 Single 
Board Computer. 
The iSBC 302 
MULTIMODULE 
board contains 
four 4K x 4 static 
RAM 
devices 
and 
sockets 
for 
two 
of 
the 
RAM 
devices 
on the 
iSBC 86/05 board. 
With 
the 
iSBC 
302 module 
mounted 
on the iSBC 88/25 board, the 


two sockets 
on the iSBC 302 module 
may be filled 
with 
4K x 4 static 
RAMs. The two sockets 
on the 
iSBC 302 module 
have extended 
pins which 
mate 


with 
two 
sockets 
on the 
base board. 
Additional 
pins 
mate 
to the 
power 
supply 
and chip 
select 
lines 
to 
complete 
the 
electrical 
interface. 
The 
mechanical 
integrity 
of the assembly 
is assured 
with 
nylon 
hardware 
securing 
the module 
in two 
places. 
With 
the iSBC 86/05 or iSBC 88/25 board 
mounted 
in the top slot of an iSSC 604/614 card- 


cage, sufficient 
clearance 
exists 
for the mounted 
iSBC 302 option. 
If the iSBC 86/05 or iSBC 88/25 
board 
is inserted 
into 
some 
other 
slot, 
the com- 
bination 
of 
boards 
will 
physically 
(but 
not 
elec- 


trically) 
occupy 
two cardcage 
slots. 


Word Size 


8/16 bits 


Memory Size 


16,384 bytes of RAM 


Cycle Time 


Provides 
"no 
wait 
state" 
memory 
operations 
on 
the iSBC 86/05 board at 5 MHz or8 MHz orthe 
iSBC 
88/25 board at 5 MHz. 


5 MHz cycle 
time - 
800 ns 
8 MHz cycle 
time 
- 
500 ns 


Memory Addressing 


Memory 
addressing 
for the iSBC 302 MUL TIMOD· 
ULE board is controlled 
by the host board via the 
address 
and chip select 
signal 
lines. 


With the iSBC 86/05 board: 


The 8K bytes of RAM on the iSBC 302 board oc- 
cupy 
the 
8K-byte 
address 
space 
immediately 
after that of the iSBC 86/05 board's 8K RAM (i.e., 
default 
configuration 
- 


iSBC 86/05 board's 
RAM - 
00000-01 FFFH 


iSBC 302 board's 
RAM - 
02000-03FFFH). 


With the iSBC 88/25 board: 


The 8K bytes of RAM on the iSBC 302 board oc- 
cupy 
the 
8K byte 
address 
space 
immediately 


after that of the iSSC 88/25 board's 
4K RAM (i.e., 
default 
configuration 
- 


iSBC 88/25 board's 
RAM - 
O-OFFFH 
iSBC 302 board's 
RAM - 
01000w02FFFH). 


Physical Characteristics 


WIDTH 
- 
2.6 in. (6.60 cm) 


lENGTH 
- 
2.3 in. (5.84 cm) 


HEIGHT 
- 
0.56 in. (1.42 cm) iSBC 302 board 
+ 
iSBC 86/05 or iSBC 88/25 board 


WEIGHT 
- 
1.25 oz (35 gm) 


Electrical Characteristics 


DC POWER 
REQUIREMENTS 
- 
720 mA at + 5V 
incremental 
power 


Environmental Characteristics 


OPERATING 
TEMPERATURE 
- 
O°C to + 55°C 


RELATIVE 
HUMIDITY 
- 
to 
90% 
(without 
con· 
densation) 


Reference Manuals 


All 
necessary 
documentation 
for 
the 
iSSC 
302 
MULTIMODULE 
board 
is 
included 
in 
the 
CPU 
board 
Hardware 
Reference 
Manuals 
(NOT 
SUP- 
PLIED). 


iSBC 86/05 - 
Order No. 143153-001 
iSBC 88/25 - 
Order No. 143825-001 


Manuals 
may 
be ordered 
from 
any 
Intel 
sales 
representative, 
distributor 
office, 
or 
from 
Intel 


Literature 
Department, 
3065 Bowers Avenue,Santa 
Clara, California 
95051. 


Part Number 


SSC 302 


Description 


8K-Byte 
MULTIMODULE 
RAM 


iSBC™ 301 
4K·BYTE RAM 
MULTIMODULE™ 
BOARD 


• On·board memory expansion to 8K 
bytes for iSBC™ 80/24 and iSBC™88/40 
Single Board Computers 


• 0.5 watts incremental power 
dissipation 


• Provides 4K bytes of static RAM 
directly on·board 


• On·board memory expansion 
eliminates MULTIBUS system bus 
latency and increases system 
throughput 


• Reliable mechanical and electrical 
interconnection 


The Intel iSBC 301 4K-Byte RAM MULTIMODULE 
Board provides 
simple, 
low cost expansion 
to double the 


RAM capacity 
on the iSBC 80/24 or iSBC 88/40 Single 
Board Computer 
to 8K bytes. This offers 
system 


designers 
a new level of flexibility 
in defining 
and implementing 
system 
memory 
requirements. 
Because 


memory 
is configured 
on-board, 
it can be accessed 
as quickly 
as the existing 
iSBC 80/24 or iSBC 88/40 


memory, 
eliminating 
the need for accessing 
the additional 
memory 
via the MULTIBUS 
system 
bus. As a 


result, the iSBC 301 board provides a high speed, cost effective 
solution 
for systems 
requiring 
incremental 


RAM expansioo. 
Incremental 
power 
required 
by the iSBC 301 module 
is minimal, 
dissipating 
only 0.5 


watts. 


The iSSG 301 board measures 
3.95" 
by 1.20" and 
mounts 
above the RAM area on the iSSG 80/24 or 
iSSG 88/40 single 
board computer. 
It expands 
the 


on-board 
RAM capacity 
from 4K bytes to 8K bytes. 


The iSSG 301 MUL TIMODULE 
board contains 
four 
1K byte static 
RAM devices 
and a socket 
for one of 
the RAM devices 
on the iSSG 80/24 or iSSG 88/40 
board. 
To 
install 
the 
iSSG 
301 
MULTIMODULE 
board, one of the RAMs is removed 
from the host 
board and inserted 
into the socket on the iSSG 301 


board. The add-on board is then mounted 
into the 
vacated 
RAM socket 
on the host 
board. 
Pins ex- 


tending 
from 
the 
RAM 
socket 
mate 
with 
the 


device's 
socket 
underneath 
(see Figure 
1). Addi- 


tional 
pins 
mate 
to the 
power 
supply 
and 
chip 


select 
lines 
to complete 
the electrical 
interface. 


The MULTIMODULE 
board is then secured 
at two 


additional 
points 
with 
nylon 
hardware 
to 
insure 


mechanical 
security 
of 
the 
assembly. 
With 
the 


iS6G 80/24 or iSSG 88/40 board mounted 
in the top 


slot 
of an iSSG 604 or iSSG 614 cardcage, 
suffi- 


cient 
clearance 
exists 
for mounting 
the iSSG 301 


option. 
If the iSSG 80/24 or iSSG tl8/40 board is in- 


serted 
into 
some 
other 
slot, 
the combination 
of 


boards will physically 
(but not electrically) 
occupy 


two cardcage 
slots. 


RAM DEVICE 
FROM HOST BOARD 


~ 


~ 
NYLON MOUTING 


~----_~ 
HARDWARE (2 PLACES) 
(SUPPLIED WITH 
iSBC'" 301 OPTION) 


Word Size 


8 bits 


Memory Size 


4096 bytes of RAM 


Access Time 


Read: 
140 ns (from READ command) 
200 ns (from ALE) 
Write: 
150 ns (from READ command) 
190 ns (from ALE) 


Memory Addressing 


Memory addressing 
for the iSBC 301 4K-Byte RAM 


MULTIMODULE 
Board 
is controlled 
by the 
host 


board via the address 
and chip select 
signal 
lines 


and is contiguous 
with 
the host board RAM. 


iSBC 80/24 and iSBC 301 board: 02000-02FFF 
iSBC 88/40 and iSBC 301 board: 00000-01 FFF 


Physical Characteristics 


Width 
- 
1.20 in. (3.05 cm) 


Length - 
3.95 in. (10.03 cm) 


Height 
- 
.44 in. (1.12 cm) iSBC 301 Board 
.56 in. (1.42 cm) 
iSBC 301 Board + host board 


Weight 
- 
.69 oz. (19 gm) 


Electrical Characteristics 
DC Power Requirements: 


10 mA at + 5 Volts 
incremental 
power 


Environmental Characteristics 


Operating 
Temperature 
- 
00 to + 550 
C 


Relative 
Humidity 
- 
to 90% 
(without 
condensa- 


tion) 


Reference Manuals 


All 
necessary 
documentation 
for 
the 
iSBC 
301 


MULTIMODULE 
board 
is 
included 
in 
the 
CPU 


board 
Hardware 
Reference 
Manual 
(NOT 
SUP· 


PLIED) 


iSBC 80/24 - 
Order No. 142648-001 
iSBC 88/40 - 
Order No. 124978-001 


Manuals 
may 
be ordered 
from 
any 
Intel 
sales 


representative, 
distributor 
office, 
or 
from 
Intel 


Literature 
Department, 
3065 Bowers 
Avenue, San- 


ta Clara, California 
95051. 


Part Number 


SBC 301 
Description 


4K 
Byte 
RAM 
MULTIMODULE 


Board 


iSBC® 254S 
BUBBLE MEMORY BOARD 


• Capacity up to 512K Bytes of Bubble 


Memory Storage 


• Automatic Error Correction Capability 


• Operates from Standard +5Vand 
+12V 


Power Supplies 


• High-Density Storage 


• DMA Capability 


• 
Non-Volatile Storage 


• High Reliability Even Under Harsh 


and Rugged Environments 


• Average Access Time of 48ms 


• 
Burst Data Rate up to 200K Bytes per 
Second 


• Software Compatible with the iRMX™ 


Operating System 


• Powerfail Data Protection 


The iSBC 254S board is a completely 
assembled and tested non-volatile 
read/write 
memory utilizing 
the Intel 
7110 one-megabit 
bubble memory. This board is offered with one, two, or four 7110 bubble memories, thus 
yielding capacities 
of 128K, 256K, or 512K bytes. 


Software 
support 
is provided 
under 
both 
iRMX/80 and iRMX/86 operating 
systems, and DMA capability 
provides the user with considerable 
flexibility 
and control. Because of the solid-state nature of this technology, 


the iSBC 254S board is ideally suited for applications 
in harsh or rugged environments. 


The iSBC 254S board is compatible 
with 16-bit addressing for 8-bit processors and with 20-bit addressing 
for 
16-bit processors. 


The following 
are trademarks 
of Intel Corporation 
'and its affiliates 
and may be used only to identify 
Intel products: 
i. Intel, INTEL, 
INTELLEC, 
MeS, 
im. ieS. ICE, UPI, ex-Poisec, 
iSBX: 


tNSITE. 
iRMX, CREDIT, AMXl80,J(Scope, 
Muttibus. 
PROMPT, 
Promware. 
Megachassis, 
Library 
Manager, 
MAIN MULTIMODULE, 
and the combination 
of MeS, ICE, sec, AMX, or iCS and 


a numerical 
suffix; 
e Q., iSBC-80. 


BUBBLE 
MEMORY 
STORAGE 
GROUP 


722 •••• 
8257 
EXPANSION 
BUBBLE MEMORY 
OMA 
ADDITIONAL 
CARD 
CONTROLLER 
CONTROLLER 
INTERFACE 


~ 
1~1 
1 


CLOCK 
SYSTEM 
BUS 


GENERATOR 
INTERFACE 


Memory Size 


128K, 256K, or 512K bytes 


All 
address, 
data, 
and 
control 
signals 
are TTL- 
compatible 
and Intel MULTlBU~ 
system compatible. 


Maximum 
Data Rate: 200K bytes/second 


Average Access Time: 48ms 
Power Supply 
Requirements 


Electrical Characteristics 


D.C. Power, supplied 
through 
MULTIBUS@connector 


Power 
Off/Power 
Fall 
Max. 


Voltage 
Tolerance 
Decay 
Rate 
Current 


+12 Volts 
±5% 
less than 
1.10 voltslmsec 
1.4A 


+5 Volts 
±5% 
less than 0.45 voltslmsec 
3.0A 


• 
Voltage 
sequencing-no 
restrictions 


• 
Power on voltage 
rate of rise-no 
restrictions 


• The power 
supply 
requirements 
shown 
are 


based on the recommended 
power fail circuitry. 


Connector 


86-pin double-sided 
PC edge connector 
with 0.40 cm 


(0.156 in.) contact 
centers. 


Mating Connector: 
Control 
Data VFB01 E43DOA1 or 


Viking 2VH43/1ANE5. 


Physical Characteristics 


Length: 30.48 cm (12 in.) 
Height: 17.15 cm (6.75 in.) 
Depth: 1.57 cm (0.62 in.) 


Note: 
Because 
of its depth, the iSBC 254S board requires 


twn ~~rrl slots in standard 
MULTI BUS card frame. 


Board Ambient 
Operating 
Temperature: 
0° to 55°C 


Non-Volatile 
Storage 
Temperature: 
- 40° to 90°C 


Additional Documentation 


iSBC 254S Reference 
Manual 
(Order No. 113844) 


INTEL MULTIBUS Specification 
(Order No. 9800683) 


Memory Components 
Handbook 
(Order No. 210830) 


Like many high density peripheral 
storage devices, 
bubble memory data is serially organized into pages 
rather than bytes. A page, varying in length from 64 
bytes (one bubble on board with error correction) 
to 
512 bytes (four bubbles on board with error correc- 
tion) is the smallest increment 
of data that can be 
transferred. A file consisting of a few large pages can 
be transferred 
faster than an equivalent file format- 
ted with smaller size pages. The iSBC 254S is offered 
with one, two, or four 7110 bubble memories which 
provide the user with the flexibility 
to match perfor- 
mance, density, and cost to the application. 


Data transfers 
are accomplished 
under 
software 
control 
by the 7220-1 bubble 
memory 
controller. 
Three distinct 
I/O modes of operation 
relate to the 
transfer of data. Choice of mode can be tailored to 
each user's application. 
Each I/O mode 
is briefly 
described 
below. 


DMA (Direct Memory Access) I/O Mode is the highest 
performance 
mode of data transfer. 
An on-board 
INTEL 7220-1 Bubble Memory Controller 
(BMC) and 
INTEL 8257 DMA controller 
work in conjunction 
to 
generate 
the MULTIBUS handshake 
protocol 
sig- 
nals. Once a data block transfer begins in this mode, 
CPU involvement 
is not 
required 
until 
the entire 
transfer is completed. This frees the CPU to perform 
other 
tasks during 
DMA transfers. 
A single 
data 
block transfer can be up to 16K bytes in length. 


Interrupt 
I/O Mode requires moderate CPU involve- 
ment for data transfers. The BMC generates an on- 
board interrupfsignal 
when the BMC FIFO (First In- 
First Out) buffer is either half full (bubble read opera- 
tion) or half empty (bubble write operation). The in- 
terrupt 
signal 
is translated 
to MULTIBUS interrupt 
line via a jumper. Using this interrupt-driven 
scheme, 
software is responsible for performing 
the appropri- 
ate transfer of data (typically 22 bytes) to or from the 
FIFO buffer when the interrupt 
occurs. 


Polled I/O Mode is the most simple. However, it is also 
the most demanding 
of CPU time. System software 
must determine when to transfer data to or from the 
FIFO by continually 
polling 
a status bit in the BMC 
status register. The status bit indicates presence or 
absence of data in the FIFO on a byte-by-byte basis. 


A set of 16 separate commands can be issued to the 
BMC on the iSBC 254S for complete system control 
of the bubble memory. Command execution can be 
viewed as divided into two phases: command execu- 
tion and result. The software responsibilities 
for the 
command 
execution 
phase consist 
of loading 
the 
BMC parametric 
registers 
(command 
dependent), 


issuing 
the desired 
command, 
and then verifying 
that the command 
was accepted. 
The appropriate 
data transfer technique 
then would transfer data as 
required. 
The result phase consists 
of the system 
software 
determining 
the 
completion 
status 
(successful or unsuccessful) 
of the command 
byei- 
ther 
polling 
the 
BMC status 
register 
(polled) 
or 
through 
an interrupt 
service routine (interrupt). 


The iSBC 254S board 
can 
run under 
either 
the 
iRMX/80 or the iRMX/86 operating 
system. 


Under the iRMX/80 operating 
system a set of two 
iRMX/80 
software 
tasks 
perform 
data 
transfers. 
Bubble I/O (BUBIO) provides the interface 
routines 
for data storage and retrieval. 
A second task, the 
Bubble Manager (BMGR) keeps track of free or avail- 
able space on the bubble 
memory 
device. BMGR 
operates 
very similar 
to the 
iRMX/80 
free space 
manager by allocating 
portions 
of bubble 
memory 
space at the request of a user task. BUBIO can be 
configured 
to run independent 
of BMGR. 


Under the iRMX/80 operating system, the iSBC 254S 
board 
is supported 
as an integral 
part of the I/O 
System Software. The iRMX 86 I/O System Software 
is implemented 
as a set of file drivers 
to support 
particular types of files and device drivers to provide 
support 
to particular 
devices 
(i.e., the iSBC 254S 
Board). Each type of file has its own file driver and 
each device has its own device driver. This provides 
great flexibility 
and device independence 
since ap- 
plication 
tasks communicate 
with 
file drivers, 
not 
with device drivers. 


Bubble memory drivers are included 
in the standard 
iRMX/86 
and iRMX/88 
package. 
Bubble 
memory 
drivers 
for iRMX 80 are available through 
Insite™ 
-INTEL's 
Software Index and Technology Exchange 
Library. 


inter 


iSBX™ 251 and 251 C 
BUBBLE MEMORY 
MULTIMODULE™ 
BOARD 


• iSBX™251 
0-60°C 
iSBX™251C 
10-40°C 
• iSBX™ MULTIMODULEn,Bus 


Compatible 


• Capacity: 128K Bytes Bubble Memory 


Storage 


• Performance: 
-Average 
Access Time: 48ms 


-Burst 
Data Rate: Up to 50K Bytes/See 


• Compatibility 
with Host DMA Controller 


• Non-Volatile Storage 


• High Reliability Under Harsh 


Environments 


• Fast Access Storage Option on iPDS™ 


System 


• Automatic Error Correction 


• Operates from Standard +5Vand 
+12V 


Power Supplies 


• Power Fail Data Protection 


• Low Power Consumption 


The Intel iSBX 251 and iSBX 251C bubble memory MULTIMODULE boards are completely 
assembled and tested 


Non-Volatile 128K-byte memory boards based on the Intel7110 one-megabit 
bubble memory and support chips. 


The iSBX 251 and iSBX 251C boards are Intel's easiest to use bubble solutions. 
The iSBX 251 and iSBX 251C 


MULTIMODULE boards may be designed into Intel SBC products 
with iSBX connectors 
as well as into any user 


manufactured 
microprocessor 
board. The bubble 
memory support 
circuitry 
and SBX connector 
on the iSBX 


251 and iSBX 251C boards provide the user with a simple interface 
to the bubble 
memory. 


The iSBX 251 and iSBX 251C boards are featured as an option on the new Intel Personal Development 
System as 


a fast access storage option 
designed 
to emulate 
disk. Typically, the bubble 
memory 
option 
provides 
a 2X 


improvement 
in system performance 
when compared 
with a floppy 
disk. Use of the iSBX 251 or iSBX 251C 


board with the iPDS system enhances 
iPDS™ system portability, 
performance 
and reliability. 


The iSBX 251 and iSBX 251C boards differ 
in specified 
operating 
temperature 
ranges. The iSBX 251 board 


operating 
temperature 
is 0-60°C. The iSBX 251C boards operating 
temperature 
is 10-40°C. These boards plug 


into any Intel iSBX single board computer 
or other processor board with an iSBX connector. The iSBX 251 board 


meets Intel iSBX specifications. 


The following 
a~e trademar~s 
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MULTI BUS, Multichannel, 
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PROMPT, 
Promware, 


AUPI, AMXJ80, 
System 
2000 
UPI, and the combination 
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IRMX, ,SSC, 
ISeX.ICE.1 
ICE, MeS, 
or UPI and a numerical 
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Patent 
licenses 
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The Intel iSBX 251 and iSBX 251C bubble 
memory 


MULTIMODULE 
boards 
are completely 
assembled 


and tested non-volatile 
memory boards. They consist 


of the Intel 7110 bubble 
memory 
and support 
cir- 
cuitry 
mounted 
on a double-wide 
MULTIMODULE 


board. 
The 
bubble 
memory 
support 
circuitry 
in- 
cludes 
the Intel 7220-1 Bubble 
Memory 
Controller 
(BMC) 
through 
which 
the 
host 
processor 
com- 
municates with the bubble storage. See Figure 1 for a 
system and bubble 
memory block diagram. 


The BMC provides 
a convenient 
8 bit bidirectional 


bus that requires only two port or I/O addresses. One 
port is used to transfer data while the other is used to 
send commands 
or view operational 
status. A set of 


sixteen commands 
are available to initiate and moni- 
tor a bubble memory data transfer. (Refer to the 7220- 
1 data sheet for more detailed 
information 
on the 


BMC commands). 


The iSBX 251 provides 
the designer 
with three I/O 


modes of data transfer 
for complete 
flexibility. 
I/O 


mode selection 
is accomplished 
through 
the use of 


on-board 
jumpers 
and user software: 


1. Polled 
2. Interrupt-driven 
mode 
3. Direct Memory Access (DMA) mode 


DMA mode requires the use of a DMA controller 
on 


the host board. 


The iSBX 251 and iSBX 251C boards 
plug into any 
Intel 
iSB~ 
Single 
Board 
Computer 
or processor 


board 
with 
an iSBX connector. 
This 
arrangement 


frees the MULTIBUS for other 
traffic 
while the host 


iSBC board accesses the bubble 
memory. 


Like many high density 
peripheral 
storage devices, 
bubble 
memory 
data is organized 
serially 
in pages 


rather than bytes. Data transfers 
are accomplished 


under software control by the 7220-1 BMC. The 7220- 
1 partitions 
the one megabit 
bubble 
me~ory 
into 


2048 pages of either 64 or 68 bytes in length. 
The 


page length is dependent 
upon the use of error de- 


tection 
and correction-64 
bytes with error correc- 


tion 
and 
68 bytes 
without. 
Data 
transfers 
are 


specified 
in terms 
of whole 
pages. 
Therefore 
the 


minimum 
amount 
of data that 
can be transferred 


during one read or write command 
is 64 or 68 bytes. 


Automatic 
error correction 
may be selected 
by en- 


abling a flag in the 7220-1 BMC. 


The iSBX 251 board can be configured 
to operate in 


polled 
mode, interrupt 
mode, or DMA mode. In the 


polled mode, the host processor 
periodically 
reads 


the 7220-1 BMC status register to obtain information 
about completion 
or termination 
of commands, 
error 


conditions, 
and the BMC's readiness to transfer data 


or accept a new command. 


In the interrupt-driven 
mode, an interrupt 
is issued by 


the 7220-1 BMC when its internal 
buffer 
is ready to 


accept 22 bytes of data during a write operation. 
In a 


read operation, 
an interrupt 
is issued whenever 
22 


bytes of data are available 
for reading 
by the host 


processor 
in addition to data transfers. 
The BMC will 


also issue an interrupt to indicate the completion 
of a 


command 
or the presence of error conditions. 


With the assistance of a direct 
memory access con- 


troller 
on the board hosting 
the iSBX 251, the BMC 


can transfer 
large blocks 
of data with 
a single 
I/O 


request. DMA mode makes use of the BMC's hand- 
shaking 
ability with a DMA controller. 


Regardless 
of the mode of data transfer, 
the host 


processor 
or DMA controller 
must 
be capable 
of 


maintaining 
a data rate of 12.5K bytes/sec. 


As shown in Figure 2, the iSBX 251 board plugs into a 
host board via the iSBX connector 
and is secured by 


three spacers with screws. A double-wide 
iSBX MUL- 


TIMODULE 
board is used and two MULTIBUS card 


slots are occupied 
in addition 
to the card slot for the 


base board. 
Dimensions 
of the board 
are given 
in 


Figures 3 and 4. Although 
the iSBX 251 board male 


connector 
has the standard 36 pins, this board also 


plugs into the expanded 
44-pin female connector. 
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Storage Capacity 


-128K 
Eight-Bit 
Bytes 
-2048 
Pages 
-Page 
Length: 
64 bytes with 
ECC 
68 bytes 
without 
ECC 


Physical Characteristics 


Width 
7.24 em (2.85 in.) 
Length 
19.05 em (7.50 in.) 


Height. 
1.27 em (0.498 in.) 


Weight. 
362.9 gm (12.8 oz.) 


Environment 


iSBX 251 board 
0-60·C 
Ambient 


iSBX 251C board 
10·-40·C 
Ambient 


Temperatures 
quoted 
are ambient 
with 
100 Ifm air 


flow. 


Operational Modes 


Polled, 
Interrupt 
Driven, 
or DMA (with 
Host 
DMA 


Controller) 


Electrical Requirements 


D.C. power, 
supplied 
through 
iSBX connector: 


D.C. 
Power 
Off/Power 
Fail 
Maximum 


Voltage 
Tolerance 
Decay 
Rate 
Current 


+12 
Volts 
:t 5% 
less than 
1.10 volts/msec 
400mA 


+5 Volts 
±5% 
less than 0.45 volts/msec 
365m A 


Performance 


Maximum 
Data Rate 
400K bits/see 


Average 
Access 
Time 
48 ms 


Average 
Transfer 
Rate 
68K bits/see 


Interface Requirements 


- TTL compatible 
-iSBX 
251 male connector 
plugs into 36-pin or 44- 


pin host female connector 
Intel No. 7906. 


Relative Humidity: 


0% to 95% 
without 
condensation 


Non·Volatile Storage temperature: 
iSBX 251C board 
- 20 to + 75°C 


iSBX 251 board 
- 40 to + 90·C 


Additional Documentation 


iSBX251 Technical 
Manual (Order Number 
112924) 


iSBX Bus Specification 
(Order Number 
142686) 


Memory Components 
Handbook 
(Order Number 
210830) 


iSBC™ 064 
RAM MEMORY 
BOARDS 


• iSBC™ 80, iSBC™ 86 and iSBC 
M 
88 
RAM memory expansion through 
direct MULTIBUS@interface 


• Auxiliary power bus and memory 


protect control logic provided for bat· 
tery backup RAM requirements 


• Jumper selectable starting address on 
any 64K boundary in a megabyte 
address space 
• On-board hardware for refresh of all 
dynamic memory elements 
• TTL compatible data, address, and 


command signal interface 


The iSSC 064 RAM Memory Soard is a member of Intel's complete line of iSSC memory and I/Oexpansion boards. Each 
board interfaces directly to any Intel iSSC 80, iSSC 86 or iSSC 88 single board computer via the MULTISUS interface to 
expand RAM memory capacity. The iSSC 064 contains 64K bytes of read/write memory implemented using dynamic 
RAM memory components. On-board refresh hardware refreshes a portion of RAM memory every 14 m.icroseconds. 
Each refresh cycle' utilizes memory for 585 nanoseconds. If a read or write cycle is in progress when a refresh cycle is 
scheduled to begin, the refresh cycle is postponed until the end of the cycle. Read/write buffers reside on each board to 
buffer-all data written into or read from the memory array. All data, address, and command signals on the bus interface 
are TIL compatible. 


READ! 


ADDRESS 
DATA 
BLOCK 
- 
WRITE 
SElECT 


BUFFERS 
JUMPERS 


4 
MEMORY 
ARRAY 
116K II 81 


CONTROL 


(BUS 
ADDRESS 
ADDRESS 
ANDSHAKE 
DECODE 
& REFRESH 


LOGIC) 


ADDRESS 
BUS 


DATA 
BUS 


CONTROL 
BUS l 


nMULTIBUS 
L! INTERFACE 


Word Size 


8 bits and 16 bits 


Memory Size 


65,536 bytes 


Access Time 


450 ns max 


Cycle Times 


Read Cycle 
- 
700 ns max 
Write 
Cycle 
- 
600/1240 
ns max 


Refresh 
Cycle 
- 
700 ns max 


Interface 


All address, 
data, 
and command 
signals 
TTL compati· 
ble. 


Address Selection 


Jumper 
selection 
of a 64K byte page in a megabyte 
ad- 
dress 
space. 


Connectors 


Edge Connectors 
- 
86-pin double-sided 
PC edge con- 
nector 
with 
0.156-in. 
contact 
centers. 


Auxiliary 
Power 


An auxiliary 
power 
bus 
is provided 
to allow 
separate 
power 
to RAM for systems 
requiring 
battery 
back up of 
read/write 
memory. 
Selection 
of 
this 
auxiliary 
RAM 


power 
bus is made via jumpers 
on the board. 


Memory Protect 


An active-low 
TIL 
compatible 
memory 
protect 
signal 
is 


brought 
out 
on 
the 
auxiliary 
connector 
which, 
when 
asserted, 
disables 
read/write 
access 
to RAM 
memory 


on the board. This input 
is provided 
for the protection 
of 


RAM contents 
during 
system 
power-down 
sequences. 


Physical Characteristics 


Width 
- 
12.00 in. (30.48 cm) 


Height 
- 
676 
in. (17.15 cm) 


Depth 
- 
0.50 in. (1.27 cm) 


Weight 
- 
14 oz (415.2 gm) 


Electrical 
Characteristics 


DC Power 
Requirements 


Normal System 
AUX Power 
AUX Power 


Voltage 
Operation 
RAM Access 
No RAM Access 


(max)1 
(max)2 
(max) 


Vcc = + 5V 
± 5% 
lee = 32A 
1.7A 
1.7A 


Voo;::: + 12V 
::!: 50/(, 
100 = 600 mA 
600 mA 
120 mA 


VSB = - 
5V 
± 5% 
ISB= 10 mA 
10mA 
3 mA 


Notes 


1. All current 
values include 
AUX power. 


2. RAM chips and RAM conlrollogic 
powered via auxiliary 
power bus. 


3. Power necessary 10 refreSh RAMs and maintain 
data, as after system 


power failure. 


Environmental 
Characteristics 


Operating 
Temperature 
- 
0 DC to + 55 DC 


Reference Manual 


98004888 
- 
iSBC 
032/048/064 
Hardware 
Reference 


Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel sales 
represen- 


tative, 
distributor 
office 
or from 
Intel 
Literature 
Depart- 


ment, 
3065 
Bowers 
Avenue, 
Santa 
Clara, 
California 


95051. 


ORDERING INFORMATION 
Part Number 
Description 


SBC 064 
64K-Byte 
RAM Board 


I~D" 
"" U"I&.P./ UO~P./ UI&.OP./U;JOl'\ 
RAM MEMORY BOARDS 


• iSBC 86, iSBC 88 and iSBC 80 board 
RAM expansion 
through 
direct 
MULTIBUS® interface 


• 32K, 64K, 128K or 256K bytes of 
read/write 
memory 


• On-board parity generator/checker 
and 
error status register 


• Requires a single. + 5 volt power supply 


• Assignable 
anywhere within 
a 16 
megabyte 
address space 


• Jumper selectable 
base address on any 
4K byte boundary 


• Auxiliary 
power bus and memory 
protect 
control 
logic for battery 
backup 
RAM requirements 


The iSBC 032A, iSBC 064A, iSBC 028A and iSBC 056A RAM memory boards are members of Intel's com- 
plete line of iSBC memory and I/O expansion boards. Each board interfaces directly to any iSBC 80, iSBC 
88 or iSBC 86 Single Board Computer via the MULTIBUS interface to expand system RAM capacity. The 
iSBC 032A, iSBC 064A, iSBC 028A and iSBC 056A boards contain 32K, 64K, 128K, or 256K bytes of 
read/write memory implemented 
using dynamic RAM components. An on-board LSI dynamic RAM con- 


troller refreshes a portion of these components every 14 microseconds. Each refresh cycle utilizes memory 
for 480 nanoseconds (maximum). 


The iSBC 032A, iSBC 064A, iSBC 028A and iSBC 056A boards generate byte oriented parity during all write 
operations and perform parity checking during all read operations. When a parity error is detected, these 
boards can generate an interrupt on the MULTIBUS interface. In addition, the row and bank of the RAM array 
containing the error are stored in a Parity Flag Register (see Figure 1).This register is accessible as a MULTI- 
BUS I/O port. An on-board LED also provides a visual indication that a parity error has occurred. To facilitate 
testing of these boards, parity generation and checking can be changed from even to odd under software 
control. 


The following 
are trademarks 
of Intel 
Corporation 
and 
may 
be used 
only 
10 deSCribe Inlel 
products: 
CREDIT, 
Index, 
loslIe. 
Intellee, 
library 
Manager, 
Megachassls, 
Mlcromap. 


MUL TIBUS, 
PROMPT, 
UPI.IlScope, 
Promware, 
MeS, ICE, iRMX, 
ISeC, 
ISaX, 
MUL TIMODULE, 
ICS. JAPX and IMMX 
Intel 
Corporation 
assumes 
no responSibility 
for the use of any 


circuitry 
other than circuitry 
embodied 
In an Inlel product. 
No other circuit 
palent 
licenses 
are implied. 


intel" 
iSBC® 032A/064A/028A/056A 


BIT POSITION 
3 
2 
1 
0 
GJ-x----x- 


--"'-"1 
]1 
t 
BOI! 
0 
PARITY 
ERROR 
SENSED 
IN BANK 
0 (EVEN 
BYTE). 


81/- 
0 
PARITY ERROR SENSED 
IN BANK 
1 (ODD BYTE). 


RI = 0 
RO~ 
1 OF MEMORY 
WAS 
READ WHEN 
PARITY 
ERROR 
SENSED. 


RJ= 1 
ROW 0 OF MEMORY 
WAS 
READ WHEN 
PARITY 
ERROR 
SENSED. 


1 = ALWAYS 
ONE. 


Word Size 


8 bits and 16 bits 


All 
address, 
data and command 
signals 
are TTL 


compatible. 


Memory Size 


32,768 
bytes 
(iSBC 
032A); 
65,536 
bytes 
(iSBC 


064A); 
131,072 
bytes 
(iSBC 
028A); 
or 262,144 


bytes (iSBC 056A) 


Memory 
- 
Base address 
is jumper 
selectable 
on 


any 4K byte 
boundary 
in a 16 megabyte 
address 


space. On-board RAM cannot cross a megabyte 
ad- 


dress boundary. 


Parity Flag Register - 
The I/O address of the Parity 


Flag Register 
is jumper 
selectable 
to be between 


OOHto OFH or 40H to 4FH. 
Access 
Time 


iSBC 032A/064A 
400 ns max. (worst case) 
360 ns max. (typical) 


iSBC 028A 
500 ns max. (worst case) 
460 ns max. (typical) 


iSBC 056A 
570 ns max. (worst case) 
530 ns max. (typical) 


Connector 


Edge connector 
- 
86 pin double-sided 
PC edge 


connector 
with 0.156 in. contact 
centers. 


Mating 
connector 
- 
Viking 
3KH43/9AMK12 
or 


equivalent. 


Cycle Times (Worst Case) 


Read 
iSBC 032A1064A/028A 
- 
600 ns max. 
iSBC 056A - 
650 ns max. 


Write 
iSBC 032A1064A1028A 
- 
600 ns max. 
iSSC 056A - 
650 ns max. 


Refresh 
iSBC 032A1064A1b28A 
- 
480 ns max. 
iSBC 056A - 
600 ns max. 


Auxiliary 
Power 


An 
auxiliary 
power 
bus 
is 
provided 
to 
allow 


separate power to RAM array for systems 
requiring 


battery 
backup 
of read/write 
memory. 
Selection 
of 


this auxiliary 
RAM power bus is made via jumpers 


on the board. 


Memory Protect 


An 
actiye-Iow 
TTL 
compatible 
memory 
protect 


signal 
is brought 
out 
on the 
auxiliary 
connector 


which, 
when asserted, 
disables 
read/write 
access 


to RAM on the board. This input is provided 
for the 


protection 
of RAM contents 
during 
system 
power- 


down sequences. 


inter 


Physical 
Characteristics 


Width 
- 
12.00 in. (30.48 em) 
Height 
- 
6.75 in. (17.15 em) 
Depth 
- 
0.50 in. (1.27 em) 
Weight 
- 
14 oz. (397 gm) 


Electrical 
Characteristics 


D.C. POWER 
REQUIREMENTS 


All configurations 
require 
only + 5 volts 
± 5%. 


Normal 
System 
Operation 
(max.) 
iSBC 032A1064A - 
4.0A (worst 
case) 
3.20A (typical) 
iSBC 028A1056A - 
4.57A (worst 
case) 
3.66A (typical) 


Auxiliary 
Power 
No RAM Access 
(max.) 


iSBC 032A1064A - 
0.41A (worst 
case) 
0.33A (typical) 


iSBC 028A1056A - 
0.55A (worst 
case) 
0.45A (typical) 


Environmental 
Characteristics 


Operating 
Temperature 
- 
O°C to + 55°C 
Relative 
Humidity 
- 
to 90% 
(without 
condensa- 


tion) 


Reference 
Manual 


143572-001 
- 
iSBC 
032A1064A1028A1056A 
Hard- 


ware 
Reference 
Manual 
(not supplied) 


Manuals 
may 
be 
ordered 
from 
any 
Intel 
sales 
representative, 
distributor 
office, 
or 
from 
Intel 
Literature 
Dept., 3065 Bowers 
Avenue, 
Santa Clara, 


California 
95051. 


Part Number 
Description 


SBC 032A 
32K-Byte 
RAM Board with 
Parity 
SBC 064A 
64K-Byte 
RAM Board with 
Parity 
SBC 028A 
128K-Byte 
RAM Board with 
Parity 
SBC 056A 
256K-Byte 
RAM Board with 
Parity 


iSBC® 028CX, OS6CX, ANQ 012CX 
iLBX™ RAM BOARDS 


• Dual port capability via MULTIBUS® and 
iLBX™ Bus Interfaces 


• Single bit error correction and double 
bit error detection via Intel 8206 ECC 
device 


• 128K byte, 256K byte and 512K byte 
versions available 


• Control status register supports 
multiple ECC operating modes 


• Error status register provides error 


logging by host CPU board 


• 16 megabyte addressing capability 


with base address selectable on 16K 
byte boundaries 


• Supports 8- or 16-bit data transfer and 


24-bit addressing 


• Auxiliary power bus and memory 


protect logic for battery back-up RAM 
requirements 


The iSB~ 
028CX, iSBC 056CX, and iSBC 012CX RAM memory boards are members of Intel's complete 
line of iSBC 


memory and I/O expansion 
boards. Each board interfaces 
directly to any iSBC 80, iSBC 88, iSBC 86, iSBC 186 and 


iSBC 286 Single 
Board Computers. 
The dual port feature 
of the CX series of RAM-boards 
allows access to the 


memory 
of both the MULTIBUS<!Jand the iLBXTM interfaces. 


In addition 
to the dual port features the "CX" 
series of RAM-boards 
provide Error Correction 
Circuitry 
(ECC) which 


can detect 
and correct 
single bit errors and detect, 
but not correct, 
double 
and most multiple 
bit errors. 


The iSBC 028CX, 
iSBC 056CX and iSBC 012CX boards contain 
128K, 256K or 512K bytes of read/write 
memory 


using 64K dynamic 
RAM components. 


Due to the iLBX dual port capability 
and on-board 
ECC features 
of the board they are ideally suited in applications 


where memory performance 
and integrity of the stored data is critical, such as financial 
transactions, 
process con- 


trol and medical 
equipment 
applications. 


General 


The iSBC 028CX, 056CX and 012CX RAM boards are 
physically and electrically compatible with the MULTIBUS 
interface 
standard, 
IEEE P796. as outlined 
in the Intel 
MULTIBUS 
specification. 
In addition 
the CX series of 
RAM-boards 
are physically 
and electrically 
compatible 
with the iLBX bus interface as outlined 
in the Intel iLBX 
Specification. 


Dual Port Capabilities 


The "cx" series of RAM-boards 
can be accessed 
by 
either the MULTIBUS 
interface 
or the iLBX interface. 
Intel's new Local Bus Extension 
interface 
(iLBX bus) is 
an unarbitrated 
bus architecture 
which 
allows 
direct 
transfer of data transfer between the CPU and the mem- 
ory boards without 
accessing 
the MULTI BUS. Due to 
the un arbitrated 
nature of the iLBX interface significant 
improvements 
in memory access times result. typically 
350% to 400%. over MULTIBUS memory access times. 


System Memory Size 


Maximum 
system 
memory 
size 
with 
this 
series 
of 
boards 
is 16 megabytes. 
Memory 
partitioning 
is in- 
dependant 
for the MULTIBUS 
interface 
and the iLBX 
interface. 


For MULTI BUS operations, 
on-board 
jumpers 
assign 
the board to one of four 4-megabyte 
pages. Each page 


is partitioned 
into 256 blocks 
of 16K bytes each. The 
smallest 
partition 
on any board 
in this series 
is 16K 
bytes. Jumpers 
assign the base address 
(lowest 
16K 
block) within the selected 
4-megabyte 
page. 


The 
iLBX 
bus memory 
partitioning 
differs 
from 
the 
MULTIBUS 
partitioning 
in that the iLBX bus address 
space consists 
of 256 contiguous 
blocks of 64K bytes 
totaling 16 megabytes. 
As with the MULTIBUS partition- 
ing the base addresses 
are set with on-board jumpers .. 


Error Checking and Correcting (ECC) 


Error checking 
and correction 
is accomplished 
with the 
Intel 8206 Error Checking 
and Correcting 
device. This 
ECC component 
in conjunction 
with the ECC check bit 
RAM array provides 
error detection 
and correction 
of 
single 
bit errors and detection 
only of double 
bit and 
most multiple 
bit errors. The ECC circuitry 
can be pro- 
grammed 
via the Control Status Register (CSR) to vari- 
ous modes while error logging is supported 
by the Error 
Status Register 
(ESR). Both CSR and ESR communi- 
cate with the master 
CPU board through 
a single 
I/O 
port. 


The processor 
board communicates 
with the ECC cir- 
cuitry via a single I/O port. This port is used for the Con- 
trol Status Register (CSR) and the Error Status Register 
(ESR). The CSR is programmed 
by the user to deter- 
mine the mode of operation 
while the ESR provides 
in- 
formation about memory errors. The iSBC 028CX, iSBC 


256CX and iSBC 012CX RAM boards are shipped with 
a Programmed 
Array Logic (PAL) device which allows 


selecting 
one of 9 posSible addresses 
for the 110 port. 


The actual selection 
is done by jumper 
configuration. 
Additional 
unprogrammed.locations 
are left in the PAL 


to allow application 
specific 110 addresses to be defined. 


There are six ECC modes of operation in the "C" 
Series 


family of RAM boards. 
Each mode is obtained 
by soft- 
ware programming 
of the CSR from the master 
iSBC 


board. The six modes are: 


a. 
Interrupt 
on any error mode 


b. Interrupt 
on non-correctable 
error only mode 


c. Correcting 
mode 


d. 
Non-correcting 
mode 


e. 
Diagnostic 
mode 


f. 
Examine 
syndrome 
word mode 


Modes (a) and (b) can be used in conjunction 
with (c) 


and (d). The six modes are described 
below. 


Interrupt 
on Any Error Mode - 
In this mode the RAM 


board will interrupt the iSBC processor 
board when any 


error (single bit or multiple 
bit) is detected 
by the ECC 


circuitry. 


Interrupt 
on Non-Correctable 
Error 
Mode 
- 
In this 


mode the RAM board will interrupt 
the iSBC processor 


board only when a non-correctable 
(multiple 
bit) error is 


detected by the ECC circuitry. 
A multiple 
bit error is not 


correctable 
by the ECC circuitry. 


Correcting 
Mode - 
In this mode the RAM board cor- 


rects 
any correctable 
error 
(single 
bit error). 
Errors 


which are not correctable 
are not modified. 
Interrupts 


are generated depending on the interrL!pt mode selected. 


Non-Correcting 
Mode - 
In this mode the RAM board 


does not correct any error. The ECC circuitry continues 
to check for errors, but no corrective 
action is taken. In- 


terrupts 
continue 
as described 
previously. 


I 
128K,256K 


OR 512K 


BYTES 
ARRAY 
I 
I 
I 


Diagnostic 
Mode - 
This mode is used for testing the 
on-board 
ECC circuitry. 
In this mode the write enable 
strobe to the ECC RAM array is continuously 
disabled. 
The diagnostic 
mode can be used to simulate errors and 
in conjunction 
with the 
"Examine 
Syndrome 
Word 
Mode" 
examine 
the check bits generated 
by the ECC 
circuitry. 


Examine 
Syndrome 
Word Mode - 
This mode, in con- 


junction with the diagnostic mode, is used for testing the 
ECC memory. 
In this mode, the syndrome 
bits/check 
bits are clocked into the ESR on every memory readlwrite 
cycle, respectively. The ESR translation PROM switches 
to a transparent 
mode in the examine 
syndrome 
word 
mode. This allows the actual syndrome word generated 
by the 8206 ECC device to be examined. 


This 8-bit register 
contains 
information 
about memory 
errors. The ESR reflects the latest error occurence. Table 
1 shows the status register format. Bits 5 and 6 show the 
failing row while bits 0 through 4 indicate which bit (of the 
16-bit data word or the 6-bit ECC syndrome 
word) is in 
error. Bit 7 is always high. 


Battery Back-up/Memory 
Protect 


An auxiliary 
power bus is provided 
to allow separate 
power to the RAM array for systems 
requiring 
backup 
of read/write 
memory. 
An active 
low TTL compatible 
memory protect signal is brought out on the auxiliary bus 
connector which, when asserted, disables readlwrite ac- 
cess to the RAM board. This input is provided 
for the 
protection 
of RAM contents during system power-down 
sequences. 


Bit 
Meaning 
6 
5 
0 
0 
Error in row 
0 


0 
1 
1 


1 
0 
2' 


1 
1 
3 


Bit 
Meaning 
4 
3 
2 
1 
0 
0 
0 
0 
0 
0 
Error in data bit 
0 
0 
0 
0 
0 
1 
1 


0 
0 
0 
1 
0 
2 


0 
0 
0 
1 
1 
3 


0 
0 
1 
0 
0 
4 


0 
0 
1 
0 
1 
5 


0 
0 
1 
1 
0 
6 


0 
0 
1 
1 
1 
7 


0 
1 
0 
0 
0 
8 


0 
1 
0 
0 
1 
9 


0 
1 
0 
1 
0 
10 


0 
1 
0 
1 
1 
11 


0 
1 
1 
0 
0 
12 


0 
1 
1 
0 
1 
13 


0 
1 
1 
1 
0 
14 


0 
1 
1 
1 
1 
15 


1 
0 
0 
0 
0 
Error in check bit 
0 


1 
0 
0 
0 
1 
1 


1 
0 
0 
1 
0 
2 


1 
0 
0 
1 
1 
3 


1 
0 
1 
0 
0 
4 


1 
0 
1 
0 
1 
5 


1 
1 
1 
1 
0 
No Error 
1 
1 
1 
1 
1 
Non-correctable 
(multiple-bit error) 


Word Size Supported 


8- or 16-bits 


Memory Size 


131,072 
bytes (iSBC 028CX board) 


262,144 
bytes (iSBC 056CX board) 


524,288 
bytes (iSBC 012CX board) 


Access Times (All densities) 


MULTIBUS® 


Read/Full 
Write 
- 
380 ns (max) 


Write 
Byte - 
530 ns (max) 


iLBX™ BUS 


Read/Full 
Write 
- 
260 ns (max) 


Write 
Byte - 
440 ns (max) 


Cycle Times (All densities) 


MULTIBUS® 


Read/Full 
Write - 
490 ns (max) 


Write Byte - 
885 ns (max) 


iLBXTl• BUS 


Read/Full 
Write - 
375 ns 


Write Byte - 
740 ns 


NOTE: 
If an error is detected, read access time and cycle times are 
extended to 255 ns (max) 


Refresh 
Cycle Time - 
15.6 J.Ls 


Refresh 
Delay Time - 
760 ns 


Memory Partitioning 


Maximum 
System 
memory 
size is 16M Bytes for both 


MULTIBUS and iLBX BUS. MULTI BUS partitioning 
is by 


Page, Block and Base, while the iLBX BUS is by Block 
and Base only. 


PAGE ADDRESS 


MULTIBUS®- 
0-4 megabytes; 
4-8 megabytes; 
8-12 


megabytes; 
12·16 megabytes 


iLBXTMBUS - 
N/A 


Board 
MULTIBUS® 
iLBX™ Bus 


(16K Bytes) 
(64K Bytes) 


iSBC<!1028C 
8 contiguous 
16K 
2 blocks 
of 


by1e blocks 
64K by1es 


iSBC<!1056C 
16 contiguous 
4 blocks 
of 


by1e blocks 
64 by1es 


iSBC<!1012C 
32 contiguous 
8 blocks 
of 


16K by1e blocks 
64K by1es 


BASE ADDRESS 


MULTIBUS®- 
Any 16K byte boundary 


iLBX™ BUS - 
Any 64K byte boundary 


Power Requirements 


Voltage 
- 
5VDC ± 5% 


Board 
Current 
Standby 


(Battery 
Backup) 


iSBC<!1028CX 
3.8A (typ.) 
2.0A (typ.) 


6.5A (max.) 
2.2A (max.) 


iSBC<!1056CX 
4.0A (typ.) 
2.1A (typ.) 


6.6A (max.) 
2.3A (max.) 


iSBC<!1012CX 
4.4A (typ.) 
2.3A (typ.) 


6.8A (max.) 
2.5A (max.) 


Environmental Requirements 


Operating 
Temperature 
- 
O°C to 55°C 


Operating 
Humidity 
- 
To 90% without condensation 


Physical Dimensions 


Width - 
30.48 cm (12 inches) 


Height -17.15 
cm (6.75 inches) 


Thickness 
- 
1.27 cm (0.50 inches) 


Weight - 
iSBC 028CX: 4699 gm (16.7 ounces); 
iSBC 


056CX: 5329 gm (19.0 ounces); iSBC 012CX: 6589 gm 
(23.5 ounces) 


Reference Manuals 


145158-001 - 
iSBC 028CXliSBC 
056CXliSBC 
012CX 


Hardware 
Reference 
Manual 


144456-001 
- 
Intel iLBX Specification 


9800683-03 
- 
Intel MULTIBUS 
Specification 


Manuals 
may be ordered 
from any Intel Sales Repre- 


sentative, 
Distributor 
Office or from the Intel Literature 


Department, 
3065 Bowers 
Avenue, 
Santa 
Clara, 
CA 


95051. 


Part Number 


iSBC 012CX 


iSBC 056CX 


iSBC 028CX 


Description 


512K byte RAM board with iLBX 


256K byte RAM board with iLBX 


128K byte RAM board with iLBX 


iSBC® 028C, 056C AND 012C 
ECC RAM BOARDS 


• iSBC® 86, iSBC® 88 RAM expansion 
through direct, IEEE P796, MULTIBUS® 
interface 


• 128K, 256K, or 512K bytes of 
read/write memory 


• Single bit error correction and double 
bit error detection via Intel® 8206 ECC 
device 


• Control status register supports 
multiple ECC operating modes 


• Error status register provides error 
logging by host CPU board 


• Base address selectable on 16K byte 
boundaries 


• Supports 8 or 16·bit transfer and 24-bit 
addressing 


• Auxiliary power bus and memory 
protect logic for battery back-up RAM 
requirements 


The iSBC® 028C, iSBC 056C and iSBC 012C RAM boards are members 
of Intel's complete 
line of iSBC memory 
and I/O Expansion 
boards. 
Each board interfaces 
directly 
to any iSBC 88 or iSBC 86 Single Board Computer 
via 
the IEEE P796 MULTIBUS® interface to expand system RAM capacity. The iSBC 028C, iSBC 056C and iSBC 012C 
boards 
contain 
128K, 256K or 512K bytes of read/write 
memory 
implemented 
using dynamic 
RAM components. 


Single bit error correction 
and double bit error detection 
are provided on the iSBC 028C, iSBC 056C and iSBC 012C 
boards via the Intel 8206 Error Checking and Correction (ECC) device. Due to the on-board ECC features of the board 
they are ideally suited in applications 
where integrity 
of the stored data is critical, 
such as financial 
transactions, 
process 
control 
and medical 
equipment 
applications. 


Refresh control of the RAM array is handled on-board by the RAM Array Control Logic. Therefore, 
no external refresh 
commands 
are necessary. 


General 


The 
iSBC 
028C, 
056C, 
and 012C 
RAM boards 
are 


physically 
and 
electrically 
compatible 
with 
the 


MULTIBUS 
interface standard, 
IEEE P796, as outlined 


in the Intel MULTIBUS 
specification. 
The capacity 
of 


each 
RAM board 
in this series 
is determined 
by the 


number 
of RAM devices on-board. 


System Memory Size 


Maximum 
system 
memory 
size with 
this 
series 
of 


boards is 16 megaby1es. On-board jumpers 
assign the 


board to one of four 4 megaby1e pages. Each page is 
partitioned 
into 256 blocks 
of 16K bytes each. 
The 


smallest 
partition 
on any board 
in this series 
is 16K 


bytes. Jumpers 
assign the base address 
(lowest 
16K 


block) within the selected 
4 megabyte 
page. 


Error Checking and Correcting (ECC) 


Error Checking and Correction 
is accomplished 
with the 


Intel 8206 Error Checking 
and Correction 
device. This 


ECC component 
in conjunction 
with the ECC check bit 


RAM array provides 
error detection 
and correction 
of 


single 
bit errors and detection 
only of double 
bit and 


most multiple 
bit errors. The ECC circuitry 
can be pro- 
grammed 
to various 
modes to provide 
full diagnostic 


testing 
of both the storage 
and check bit RAM arrays. 


The processor 
board communicates 
with the ECC cir- 


cuitry via a single 110 port. This port is used for the Con- 
trol Status Register (CSR) and the Error Status Register 
(ESR). The Control Status Register 
is programmed 
by 


the user to determine 
the mode of operation 
while the 


Error 
Status 
Register 
provides 
information 
about 


memory 
errors. The iSBC 028C, iSBC 256C and iSBC 


012C RAM boards are shipped with a Programmed 
Ar- 


ray Logic (PAL) device which allows selecting 
one of 9 


possible addresses for the 1/0 port. The actual selection 
is done 
by jumper 
configuration. 
Additional 
unpro- 


grammed 
locations 
are left in the PAL to allow applica- 


tion specific 
1/0 addresses 
to be defined. 


There 
are six ECC modes 
of operation 
on the "C" 
Series Family of RAM boards. 
Each mode is obtained 


by software 
programming 
of the CSR from the master 


iSBC board. The six modes are: 


a. 
Interrupt 
on any error mode 


b. 
Interrupt 
on non-correctable 
error only mode 


c. Correcting 
mode 


d. 
Non-correcting 
mode 


e. 
Diagnostic 
mode 


f. Examine 
syndrome 
word mqde 


Modes (a) and (b) can be used in conjunction 
with (c) 


and (d). The six modes are described 
below. 


Interrupt on Any Error Mode - 
In this mode the RAM 


board will interrupt 
the iSBC processor 
only when any 


error 
(single 
or multiple 
bit) is detected 
by the ECC 


circuitry. 


Interrupt 
on Non-Correctable 
Error Mode - 
In this 


mode the RAM board will interrupt 
the iSBC processor 


only 
when 
a non-correctable 
(multiple 
bit) error 
is 


detected 
by the ECC circuitry. 
A multiple bit error is not 


correctable 
by the ECC circuitry. 


Correcting 
Mode - 
In this mode the RAM board cor- 


rects 
any correctable 
error 
(single-bit 
error). 
Errors 


which are not correctable 
are not modified. 
Interrupts 


are 
generated 
depending 
on the 
interrupt 
mode 


selected. 


Non-Correcting 
Mode - 
In this mode the RAM board 


does not correct any error. The ECC circuitry continues 
to check for errors, but no corrective 
action is taken. In- 


terrupts 
continue 
as described 
previously. 


Diagnostic 
Mode - 
This mode is used for testing the 


on-board 
ECC circuitry. 
In this mode the write enable 


strobe to the ECC RAM array is continuously 
disabled, 


The diagnostic mode can be used to simulate errors and 
in conjunction 
with the 
"Examine 
Syndrome 
Word 


Mode" 
examine 
the check bits generated 
by the ECC 


circuitry. 


Examine Syndrome Word Mode - 
This mode, in con- 


junction 
with the "Diagnostic 
Mode", 
is used for testing 


the ECC memory. 
In this mode, 
the syndrome 
bitsl 


check 
bits are clocked 
into the Error Status 
Register 


(ESR) on every memory readlwrite 
cycle, respectively. 


The ESR translation 
PROM switches 
to a transparent 


mode 
in the Examine 
Syndrome 
Word 
Mode. 
This 


allows the actual syndrome word generated by the 8206 
ECC device to be examined. 


This 8-bit register contains 
information 
about memory 
errors. 
The ESR reflects 
the latest error occurance. 


Table 1 shows the status register format. Bits 5 & 6 show 
the failing row while bits 0 through 
4 indicate which bit 
(of the 16-bit data word or the 6-bit ECC syndrome word) 
is in error. Bit 7 is always high. 


Bit 
Meaning 
6 
5 
0 
0 
Error in row 
0 
0 
1 
1 


1 
0 
2 


1 
1 
3 


Bit 
Meaning 
4 
3 
2 
1 
0 


0 
0 
0 
0 
0 
Error in dilta bit 
0 
0 
0 
0 
0 
1 
1 


0 
0 
0 
1 
0 
2 
0 
0 
0 
1 
1 
3 


0 
0 
1 
0 
0 
4 
0 
0 
1 
0 
1 
5 


0 
0 
1 
1 
0 
6 
0 
0 
1 
1 
1 
7 
0 
1 
0 
0 
0 
8 


0 
1 
0 
0 
1 
9 


0 
1 
0 
1 
0 
10 


0 
1 
0 
1 
1 
11 
0 
1 
1 
0 
0 
12 
0 
1 
1 
0 
1 
13 
0 
1 
1 
1 
0 
14 
0 
1 
1 
1 
1 
15 


1 
0 
0 
0 
0 
Error in check bit 
0 


1 
0 
0 
0 
0 
1 


1 
0 
0 
1 
0 
2 
1 
0 
0 
1 
1 
3 
1 
0 
1 
0 
0 
4 
1 
0 
1 
0 
1 
5 


1 
1 
1 
1 
0 
No Error 


1 
1 
1 
1 
1 
Non-correctable 
(multiple-bit error) 


NOTE: Bit 7 is alwayshigh 


Battery Back-up/Memory 
Protect 


An auxiliary 
power bus is provided 
to allow separate 


power to the RAM array for systems 
requiring 
backup 


of read/write 
memory. 
An active 
low TTL compatible 


memory 
protect 
signal is brought 
out on the auxiliary 


bus connector which, when asserted, disables read/write 
access to the RAM board. This input is provided for the 
protection 
of RAM contents during system power-down 
sequences. 


Word Size Supported 


8 or 16-bits 


Memory Size 


131,072 Bytes (iSBC 028C) 


262,144 
Bytes (iSBC 056C) 


524,288 
Bytes (iSBC 012C) 


Access Times (All Densities) 


Read/Full 
Write 
- 
350 ns (max) 


Write 
Byte - 
530 ns (max) 


Cycle Times (All Densities) 


Read/Full 
Write 
- 
460 ns (max) 


Write 
Byte - 
885 ns (max) 


NOTE: If anerrorisdetected,readaccesstimeandcycletimesare 
extendedby 255 ns. 


Refresh Times 


Refresh 
Cycle 
Time - 
15.6 P.s 


Refresh 
Delay Time 
- 
760 ns 


Memory Partitioning 


Maximum 
System 
RAM size is 16M Bytes 


PAGE ADDRESS 
(4M BYTES) 


1 of 4 megabyte 
pages as follows: 
0-4 megabytes; 
4-8 


megabytes; 
8-12 megabytes; 
12-16 megabytes 


BLOCK 
ADDRESS 
(16K BYTES) 


iSBC 
028C 
RAM 
board 
- 
8 contiguous 
16K Byte 


Blocks (128K Bytes) 


iSBC 
056C 
RAM board 
- 
16 contiguous 
16K Byte 


Blocks (256K Bytes) 


iSBC 
012C 
RAM board 
- 
32 contiguous 
16K Byte 
Blocks (512K Bytes) 


BASE ADDRESS 


Any 16K Byte Boundary 


Power Requirements 


Voltage 
- 
5VDC ± 5% 


Current - 
iSSC 028C 6.5A max; iSSC 056C 6.6A max; 
iSSC 012C 6.8A max 


Standby 
- 
iSSC 028C 2.2A max (battery 
backup); 
iSSC 056C 2.3A max; iSSC 012C 2.5A mal' 


Environmental Requirements 


Operating 
Temperature 
- 
O°C to 55°C 


Operating 
Humidity - 
To 90% without condensation 


Physical Dimensions 


Width - 
12 inches (30.48 cm) 


Height - 
6.75 inches (17.15 cm) 


Thickness 
- 
0.50 inches (1.27 em) 


Weight 
- 
iSSC 028C 16.7 ounces 
(4699 gm); iSSC 


056C 19.0 ounce~ (5329 gm); iSSC 012C 23.5 ounces 
(6589 gm) 


Reference Manuals 


145183.001 
- 
iSSC 028CliSSC 056C/iSSC 012C Hard- 


ware Reference 
Manual 


Manuals rnay be ordered from any Intel Sales Represent- 
ative, 
Distributor 
Office, 
or from the 
Intel 
Literature 


Department, 
3065 Sowers 
Avenue, 
Santa 
Clara, 
CA 


95051. 


Part Number 


SSC 012C 


SSC 056C 


SSC 028C 


Description 


512K Syte RAM board with ECC 


256K Syte RAM board with ECC 


128K Syte RAM board with ECC 


iSBC™ 012B 
RAM MEMORY 
BOARDS 


• iSBC 86, iSBC 88 and iSBC 80 board 
RAM expansion through direct 
MULTIBUS® interface 


• 512K of read/write memory 


• On-board parity generator/checker and 
error status register 


• Requires a single + 5 volt power supply 


• Assignable anywhere within a 16 
megabyte address space 


• Jumper selectable base address on any 
16K byte boundary 


• Auxiliary power bus and memory pro- 
tect control logic for battery backup 
RAM requirements 


The iSBC 012B RAM memory 
board is a member of Intel's 
complete 
line of iSBC memory and I/O expansion 
boards. 
The board interfaces 
directly 
to any iSBC 86, iSBC 88 or iSBC 80 Single 
Board Computer 
via the 
MULTIBUS 
interface 
to expand 
system 
RAM capacity. 
The 
iSBC 
012B board 
contains 
512K bytes 
of 
read/write 
memory 
implemented 
using dynamic 
RAM components. 
An on-board 
dynamic 
RAM controller 


refreshes 
a portion 
of these 
components 
every 16 microseconds. 
Each refresh 
cycle 
utilizes 
memory 
for 


550 nanoseconds 
(maximum). 


The iSBC 012B board generates 
byte oriented 
parity during all write operations 
and performs 
parity checking 
during 
all read operations. 
When 
a parity 
error 
is detected, 
the board can generate 
an interrupt 
on the 
MULTIBUS interface. 
In addition, 
the row and bank of the RAM array containing 
the error are stored in a Parity 


Flag Register. This register 
is accessible 
as a MUL TIBUS I/O port. An on-board 
LED also provides 
a visual in- 


dication 
that a parity error has occurred. 


The 
follOWIng 
are trademarks 
of 
Intel 
CorporatIon 
and 
may 
be used 
to describe 
Inlel 
products: 
CREDIT, 
Index, 
InSJle, Inlellec, 
Library 
Manager, 
Megachassis, 
Micromap, 


MULTI BUS, PROMPT, 
UPI, ,.,Scope. 
Promware, 
MeS, 
ICE, IAMX, 
iSBC. 
,SBX, 
MULTI MODULE, 
les, 
IAPX and iMMX. 
Intel Corporation 
assumes 
no responsibility 
lor the use of any 


CirCUItry other 
than cirCUitry 
embodied 
In an Intel 
product. 
No other 
circuit 
patent 
licenses 
are implied. 


Word Size 


8 bits and 16 bits 


Memory Size 


524,288 bytes (iSBC 012B) 


Access 
Time 


330 nsec (worst case) 
300 nsec (typical) 


Cycle Times (Worst Case) 


Read - 
500 ns max. 


Write - 
500 ns max. 


Refresh - 
550 ns max. 


Interface 


All address, data and command signals are TIL 
compatible. 


Memory - 
Base address is jumper selectable on 


any 16K byte boundary in a 16 megabyte address 
space. On-board RAM cannot cross a 4 megabyte 
address boundary. 


Parity Flag Register - 
The I/O address of the Parity 


Flag Register is jumper selectable to be between 
OOHto OFH or 40H to 4FH. 


Connector 


Edge connector 
- 
86 pin double-sided 
PC edge 


connector with 0.156 In. contact centers. 


Mating 
connector 
- 
Viking 
3KH43/9AMK12 
or 


equivalent. 


Auxiliary 
Power 


An auxiliary 
power 
bus 
is provided 
to allow 


separate power to RAM array for systems requiring 
battery backup of read/write memory. Selection of 


this auxiliary RAM power bus is made via jumpers 
on the board. 


Memory Protect 


An active-low 
TIL 
compatible 
memory 
protect 


signal is brought out on the auxiliary connector 
which, when asserted, disables read/write access 
to RAM on the board. This input Is provided for the 
protection of RAM contents during system power- 
down sequences. 


Physical 
Characteristics 


Width - 
12.00 in. (30.48 cm) 


Height - 
6.75 in. (17.15 cm) 
Depth - 
0.50 in. (1.27 cm) 
Weight - 
14 oz. (397 gm) 


Electrical 
Characteristics 


D.C. POWER REQUIREMENTS 


All configurations 
require only + 5 volts ± 5%. 


Normal System Operation (max.) 


4.8A (worst case) 
3.46A (typical) 


Auxiliary Power No RAM Access (max.) 


1.35A (worst case) 
0.88A (typical) 


Environmental 
Characteristics 


Operating Temperature - 
O°C to + 55°C 


Relative Humidity 
- 
to 90% (without condensa- 


tion) 


Reference 
Manual 


143865·001 - 
iSBC 056B/012B Hardware Refer- 


ence Manual (not supplied) 


Manuals 
may be ordered 
from 
any Intel 
sales 


representative, 
distributor 
office, 
or from 
Intel 


Literature Dept., 3065 Bowers Avenue, Santa Clara, 
California 95051. 


Part Number 
Description 


SBC 012B 
512K-Byte RAM Board with Parity 


ARTICLE 
REPRINT 


Choose the right level 
of memory-error 
protection 


WIth three basic methods for handling 
memory errors, selecting the right 
approach bolla down not to maximizing 
reliability but to determining the effect and 
frequency of the errors. 


Choosing the best approach to~dling 
memory 
-particularly 
RAM-errors 
does not necessarily 
mean selecting the one offering the highest reliability. 
1b minimize the impact ofmemory error protection on 
system cost and performance, 
the goal should be to 


select an approach that provides a level of reliability 
that meets-but 
does not exceed-the 
requi!'ements 


ofthe application. The level ofreliability required by a 
system should be a function of the application's sen- 
sitivity to memory errors and of the frequency with 
which errors will occur. 
When selecting a RAM board, there are three basic 
error-protection 
approaches: 
• Unprotected 
memory-designing 
the total sys- 


tem with a maximum degree of tolerance for errors in 
the RAM data. 
• Parity-designing 
the RAM array so that it can 


detect when a single-bit error has occurred. 


• ECC (for error-eorrecting 
code or circuitry)- 


designing 
the RAM array 
so that it not only can 
detect 
the majority 
of errors 
but also can correct 


single-bit errors without failing. 
There are also three major reasons why interest in 


RAM reliability has grown. First, the memory arrays 
themselves 
have grown. In 1978, the typical single- 


board computer system had 16to 32 kbytes of RAM, 
and systems with as few as 512bytes of RAM were not 
uncommon. 'Ibday, the typical single-board computer 
system has 64 to 128kbytes of RAM, while the llu-gest 
systems have up to 512 kbytes or 1 Mbyte of RAM. 
Microcomputers with 16 Mbytes of RAM are not too 
far off. It is natural to assume that these larger RAM 
systems are likely to fail more often than the earlier 
systems, which were up to 2000 times smaller. 


Drww Lucy, Memory Board Product Manager 
Inlel9orP. 
5200 N.E. E!am '!bung Pkwy.• Hillsboro. OR 97123 


The second reason is a growing trend toward stor- 


ing programs 
as well as data in dynamic RAMs in- 


stead of in ROM or EPROM. The combined hard and 
soft error rate for these volatile memory devices has 
always been higher than that of equivalently 
sized 


nonvolatile EPROMs. The consequences of an altered 
program instruction 
can be much more serious than 


those of an altered data byte. 


The third and, perhaps the least understood, 
rea- 


son is Intel's discovery of alpha-particle-related 
soft 


errors, which can affect 64-kbit dynamic RAMs (see 
"The Rise of Alpha Particles"). 
These devices are 


essential for microcomputer memories larger than 128 
kbytes to be economically and technically practical. 


failure. 
hard end 10ft 


When a RAM component fails to retain stored data 


correctly, that failure can be either "hard" or "soft." 
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Hard errors, which can affect single or multiple bits, 
are caused by permanent 
defects in the component 
such as shorts, 
open leads, microcracks, 
or other 
flaws. A hard error causes the device to consistently 
return the same value for the failed bit regardless 
of 
what is subsequently 
written to that bit. 
Soft errors 
are random, 
nonrecurring, 
and non- 
destructive, 
and affect only a single bit. They cause 
the values ofbits to be inverted, but do not prevent bit 
cells from correctly 
storing 
data from subsequent 


writes. 
Such errors can be caused by noisy system 
environments, 
poor system design, or rare combina- 
tions of noise, data patterns, 
and temperature 
that 
push the RAM beyond its operating limits. 
However, in a well-designed system, the primary 
source of soft errors is the ionizing radiation of alpha 
particles, 
which have enough energy to change the 
cell charge 
in semiconductor 
substrates 
with high 
impedance nodes. These helium nuclei are emitted 
naturally by the environment but primarily by radio- 
active impurities 
in component packaging material. 


As with all soft errors, alpha-particle-induced 
errors 


can be purged by rewriting 
the correct data to the 
bit cell. 


During a RAM's useful life, errors occur randomly; 
over a given period oftime, the error rate is a constant 
for a particular 
set of operating conditions (voltage, 
temperature, 
etc.). The failure rate of a RAM is ex- 
pressed as the percent probability that the device will 
fail during a given number of hours of operation. The 
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mean time between failure (MTBF) for a single device 
is simply the reciprocal of its failure rate (a device 
with a failure rate of1% per 1000hours has an MTBF 
oflOO,OOOhours). Failure rates are additive: A compo- 
nent's hard and soft failure rates can be measured 
independently 
and then added together 
to get the 


device's combined failure rate. More important, 
the 


failure rate for a collection of devices assembled se- 
rially (all devices must work for the system to func- 
tion) is the sum of the failure rates for the individual 
components. 
In the case of a RAM array, in which all the devices 


are the same, the system failure rate is equal to the 
failure rate of the device times the number of devices. 
The MTBF of a RAM array is thus inversely propor- 
tional to' the number of devices in the system-doub- 
ling the number of RAMs in the array cuts the MTBF 
ofthe system in half. (However, these relationships do 
not apply to memory with ECC, which is not a serial 
system.) 
Figure 
1 illustrates 
how a RAM array's 


MTBF varies with the number of devices in the array 
for a range of device-failure rates. 


The capacitors, diodes, buffers, and other support 


logic also contribute 
to reducing a memory system's 


MTBF. However, the failure rate for these MSI, SSI, 
and TTL components, 
whose failures are almost al- 


ways hard, 
is quite low compared 
with the RAM 


array. 
For example, 
Intel's A-series 
RAM boards 


(iSBC 056A, iSBC 028A, etc.), which include parity, 
were tested at 55°C for a total of 73,200 board hours, 


2. Unprotected 
memory will hIM! a allghtly 
higher MTBF than parlty-prolKted 
memory, 


becau •• '- 
devices are required. 
However, note the subatllntlallncreaee 
In MTBF 


gained by using 64-kblt RAMs rather than 16-11devices. 


Much of the recent interest in RAM system re- 


liability stems from concern over alpha-particle soft- 
error rates reported for the initial 64-kRAMs. Alpha 
particles affect alldynamicRAMs,but 64-kRAMsare 
mostsusceptibleto alphaparticles than smallerRAMs, 
primarily because their bit storage cells are much 
smaller. This size reduction reduces the amount of 
stored electric charge (critical charge) used to dis- 
tinguish between a 1and a O. In the transition from16-k 
to 64-kcomponents,the critical charge wasreduced to 
the point where a significant percentage of the alpha 
particles striking the storage cell contained enough 
energy to alter the contents ofthat cell. 
Those early reports, in fact, indicated that the 64-k 


. RAMwas in the initial stages ofa process that all new 
semiconductormemories go through. As semiconduc- 
tor manufacturers gain experience with a new device, 
the failure rate drops dramatically. The figure illus- 
trates this processforthe Intel 1103(I-k),2107(8-k),and 
2117(l6-k) dynamic RAMs. The degree and rate of 
improvementin 64-kRAMs have been even more dra- 
matic because semiconductormanufacturers were fac- 
ing the unexpectedly severe alpha-particle soft-error 
problem for the first tiine. 


With a potentially multibillion-dollar market at 


stake, the alpha-particle problemhas been attacked on 
a number offronts. Packaging-materialmanufacturers 
have reduced the levelofradioactivethorium and ura- 
nium in their products. Meanwhile,64-kdesigns have 
been changed to make them more immune. Different 
processing techniques have been developedthat allow 


or 8.4 board years, without 
a single failure in the 
support logic. 


Parity and ECC error protection apply primarily to 
the RAM components, since much ofthe support logic 
is "downstream" 
from where the error detection/cor- 


rection takes place. If an application is so sensitive to 
memory errors that it must be protected 
from rare 
support-logic failures, then the design will probably 
require completely redundant 
memory systems. For 


the 
purpose 
of comparing 
error-protection 
ap- 


proaches, this small, but not insignificant, source of 
memory-system 
failures will be ignored. 


Unprotected 
and commonplace 


The most commonly used memory for microcompu- 
ters has no inherent error protection. These systems 
rely on relatively 
high memory MTBFs and tech- 


niques like the rejection of data that fall outside pre- 
defined limits and the use of feedback from the ap- 
plication environment 
to recognize error conditions. 
Corrective action for these systems is limited to retry- 
ing some sequence of code and then shutting down the 


morecharge to be heldin a storage cellofa givenarea. 
Finally, coatings have been developedto absorb much 
ofthe alpha particle's energy before it reaches the die. 


'Ibday, Intel 64-k dynamic RAMs have a soft-error 


rate ofapproximately 0.1%per 1000hours and a hard- 
failure rate ofapproximately 0.02%per 1000hours (at 
55·C); the combined failure rate is 0.12% per 1000 
hours. This is only 10%higher than the devicefailure 
rate fortoday'scommerciall6-kRAMs.Onaper-kilobit 
basis, today's64-kRAMsare morethan three anda half 
times as reliable as 16-kRAMs. 
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system in an orderly 
fashion if the error condition 


persists. 


This approach works best when RAM is used pri- 


marily for data storage. 
Critical code segments, 
in- 
cluding error 
handlers, 
are stored in EPROM and 


ROM. For example, a microcomputer-controlled 
lathe 


could regulate the feed rate of the cutting tool and the 
flowof lubricant being sprayed on the work piece. The 
.desired feed rate for the material being machined and 
the cutting tool being used could be stored in RAM. 
The amount of lubricant applied could be calculated, 
based on a temperature 
input from the cutting tool. 


If a RAM error causes the feed rate parameter 
to 


increase, 
the microcomputer 
may be able to detect 


that it exceeds some predefined 
limit. If not, the 


temperature 
input from the cutting tool will rise, first 


causing more lubricant to be applied. If the tempera- 
ture input remains high, the microcomputer 
might 


revert to default feed rate stored in EPROM or ex- 
ecute'an 
EPROM resident 
routine that retracts 
the 
tool, shuts off the lubricant, and notifies the operator. 
If the memory error were not detected 
by the pro- 


gram's limit checking or temperature 
sensing rou- 


tines, then the work piece, and possibly the cutting 
tool, could be ruined. 


How often will this or a similar catastrophe 
occur? 


It depends on the degree of fault tolerance and the 
size of the memory. Assuming 
no fault tolerance, 


Fig. 2 shows how often various size RAM arrays will 
fail. If the lathe controller required 32 kbytes of RAM 
and the memory was implemented 
with 16-k RAMs, 
that RAM array could be expected to develop an error 
once every six and a half years of operation, on aver- 
age. That is, one or perhaps 
two pieces would be 
ruined by a RAM failure during the useful life of the 
equipment-almost 
certainly 
an acceptable 
failure 
rate for this application. 


What if the application 
required 
128 kbytes 
of 
RAM? Using 16-k RAMs, the memory array would 
fail, on average, once every 1.6 years ofoperation. But 
if 64-k RAMs were used instead-or 
one-quarter 
as 
many devices-the 
memory would fail only once in 
5.9 years 
of operation, 
for an MTBF almost four 
times better. 
Compared 
with the other 
two approaches, 
un- 
protected memory is inexpensive as well as simple to 
design, implement, and test, especially with LSI dy- 
namic RAM controllers 
available. 
An unprotected 
memory board will cost about 10% less than a board 
with parity 
and about 30% less than a board with 
ECC. However, fault tolerance must be designed into 
the system, and despite this effort, eventually a mem- 
ory error will go undetected and the system will fail. 


Simple addition 


Parity 
is a simple memory-protection 
technique 


that typically appends one bit to every byte of mem- 
ory. The contents of the parity bit are determined by 
Exclusive-oRing the data bits in the word, which re- 
sults in the value ofthe parity bit. When the word isread, 
the memory system 
performs 
this operation 
again 


and checks to see that the result matches the parity 
bit's value. If it does not, then one bit (or any odd 
number ofbits) in the data word has changed since the 
word was written. 
This error generates 
an interrupt 
from the memory 
to the single-board 
computer, 
which, in response, will usually execute an EPROM- 
resident shutdown or restart 
routine. 
The system response to a parity error is the same as 


the system's response to an error condition detected 
through feedback, except that virtually all memory 
errors will be detected. 
Note that parity cannot de- 
tect a double-bit error in a data word. However, in a 
dynamic RAM array, the probability oftwo bits failing 
in the same word is extremely 
small. 


Figure 
2 graphically 
presents 
the MTBFs for a 


variety of memory sizes with parity using both 16-k 
and 64-k RAMs. Once again, for any given memory 


size, the 64-k-based system is more than three and a 
half times more reliable. 
A comparison of the un- 
protected 
and parity memory MTBFs in Fig. 2 re- 
veals an interesting 
effect of parity. Although parity 


allows detection of virtually all memory errors, it also 
reduces 
the MTBF of the memory 
array 
by 11%, 
because the parity system requires additional mem- 
ory chips, which in turn increase the system failure 
rate. Even so, a 256-kbyte, 64-k-RAM-basedmemory 
with parity will produce a detectable single-bit error 
only once every 2.6 years of operation. 


The primary benefit of parity is that the system will 
reliably detect close to 100% of all memory errors. 
This allows the orderly shutdown and restarting 
of 
the microcomputer 
system. There are also two pri- 


mary limitations: Parity produces the lowest memory 
MTBF of the three 
approaches 
and provides very 


little information as to the source or nature 
of the 
error. 


Some parity boards, such as the Intel iSBC 056A 
and iSBC 012B, include parity-error 
status registers 
which can isolate the memory error to one quadrant of 
the RAM array. This information can be used by a 
diagnostic routine to search memory and identify the 
faulty memory location. If the faulty memory location 
is in a data area, the system may elect to continue 
operation. 
If the error occurred in an area used to 
store programs, or if the system cannot search mem- 
ory, there is usually no alternative except to stop and 
reboot the system. 


Whether ECC stands for error-correcting 
code or 
error-correcting 
circuitry, the term refers to a data- 


encryption 
scheme that appends a number of ECC 
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check bits to every memory word. The number of 
ECC bits required depends on the number of bits in 
the data word and on whether double-bit errors are to 
be detected. 
An 8-bit data word will reauire four or 


five ECC bits. A 16-bit word will require five or six 
bits and, a 32-bit word will require six or seven bits. 
Thus, 
the 
overhead 
associated 
with 
ECC grows 
rapidly as the data words get smaller-for 
a 32-bit 
word, the minimum overhead is 19%, but for an 8-bit 
word, it is 50%. 
So many ECC check bits are required because they 
are used not only to detect errors, but also to identify 
which bit failed. This information allows an LSI ECC 
controller chip iR. the memory system to correct the 
error before passing the data to the CPU. In addition, 
most ECC systems can detect when two bits in the 
same word fail. However, standard 
ECC cannot cor- 
rect double-bit errors. The probability of a double-bit 
error occurring defines the MTBF of an ECC-pro- 
tected memory array. 


ECC-protected 
memory is not a serial system. One 


or more elements of the system can fail without caus- 
ing a system 
failure. 
This greatly 
complicates the 


calculation of system-failure probabilities. Preventive 
maintenance 
also has a significant 
effect on ECC 


memory-failure rates, as do the hard failure modes of 
a particular RAM device type. Figure 3 shows MTBF 
data for a RAM array with 16-bit words and six ECC 
check bits per word. (Those interested 
in the theory 
or mechanics of calculating MTBFs for ECC memory 
can obtain a two-part 
Intel application note, AP-46, 
AP-73; AP-73 also contains a listing of the Fortran 
program that was used to generate the data in Fig. 3.) 
The advantages 
of ECC are pronounced: An ECC 


system's MTBF will be more than 20 times higher 
than the MTBF of an equivalent-sized unprotected or 
parity-protected 
memory. With preventive 
mainte- 
nance, ECC memory MTBFs can be over two orders 
of magnitude higher. With this kind of MTBF enhan- 
cement, the failure of a I-Mbyte memeory array be- 
comes a once-in-a-lifetime 
event. 
In addition, 
the 


probability 
of an undetected 
(a triple-bit) 
memory 
error is effectively zero. However, the essentially per- 
fect data integrity 
achieved with ECC brings on sig- 
nificant drawbacks. 
For one thing, the use of ECC increases the mate- 


rial, assembly, and test costs of building a memory 
board. The major portion of the material cost increase 
comes from adding six ECC ~AM components for 
every 16 data RAMs and from the ECC controller 
chip. Additional material costs are associated with a 
more complex PC board and with error logging. The 
net effect is an approximate 35%increase in price for a 
completed 16-hit RAM board. At today's prices, ECC 
will add about $1000 to the list price of a 512-kbyte 
RAM board. 
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Another disadvantage 
is an increase in the access 


and cycle times incurred by the system to do the error 
checking. 
Depending 
on how the ECC is imple- 


mented, the increase in data-word access time Will be 
between 50 and 200 ns, and the increase in cycle time 
will be between 100 and 300 ns. A comparison of data 
sheets for ten 5l2'-kbyte Multibus RAM boards re- 
veals parity-board 
access times ranging from 250 to 


300 ns, while ECC-board 
access times ranged from 


300 to 460 ns. Parity-board 
cycle times ranged from 


400 to 500 ns; ECC-board cycle times, from 500 to 700 
ns. The effect 
on actual 
system 
performance, 
of 
course, 
will depend 
on the system's sensitivity 
to 


memory-access time. 


There is an additional performance penalty associ- 


ated with accessing 8-bit data in a memory system 
with ECC implemented for 16-bit words. This affects 
both 8-bit microprocessors and 16-bit microprocessors 
when they operate on 8-bit data. The ECC check bits 
must be calculated for the full 16-bit word, which 
means that to write 8 bits, a 16-bit word must first be 
read. The new data byte is merged into the 16-bit 
word; then the full word is placed in memory with a 
new set of check bits. This read-modify-write 
process 


can double the write access time of the memory. 


A third drawback of ECC is increased power con- 


sumption, stemming from the 35% increase in mem- 
ory components 
and the additional 
support 
logic 


required. 
Comparing the Multibus 512-kbyte boards 


again reveals that the parity-protected 
boards con- 


sumed 7 to 17W while the ECC boards consumed 10to 
as much as 59 W. 
While implementation 
differences make compari- 
sons more complicated than numbers vs numbers, an 
important 
fact must be considered: The best ECC 
board required 
over 40% more power than the best 
parity board. 


Choosing the right approach 


Evidently, 
increased 
memory-system 
reliability 
has its price. Designing fault tolerance into a micro- 
computer 
system requires 
additional 
development 
time and effort. Parity slightly increases the cost of 
memory and reduces the system's MTBF. ECC sig- 
nificantly increases memory cost, access times, and 
power consumption. The only practical solution is to 
balance the cost of the potential effects of a memory 
failure against the costs ofimplementing error protec- 
tion. The final choice wi1ldepend on both the applica- 
tion-specific consequences 
of a failure and the fre- 
quency of failure. 
For many applications, as in the lathe example, the 
consequences 
of undetected 
memory failure may be 
serious, but the occurrence 
may be rare enough to 
make the costs of memory protection higher than the 
costs resulting 
from an error. Applications not se- 
riously affected by occasional memory errors include 
graphics 
terminals, 
office-automation 
systems, 
speech synthesis/recognition, 
building-environment 
control, and some data-acquisition, 
instrumentation, 
and machine-control 
applications. 
In these applica- 
tions, a memory error either may not significantly 
affect the system output or the consequences may be 
small and are easily correctable. 
For these applica- 
tions, a well-designed unprotected 
memory board is 
the most cost-effective choice (Fig. 4). 
If the designer 
concludes that the system cannot 
tolerate 
undetected 
errors 
occurring 
with the fre- 
quency implied by the required memory size, the next 
thing to do is determine 
the consequences 
of a de- 
tected memory error on the system. The impact could 
be significantly different from that of an undetected 
error. 
When a memory 
error 
is not detected, 
the 
system continues to run in an unknown state. In this 
condition, the system might cause additional damage 
beyond the original memory error. 
If the memory 
error can be detected, then the system can respond in 
a controlled fashion, thus avoiding additional system 
errors. 
If a memory error is detected 
(parity inter- 
rupt) in the lathe example, the microcomputer could 
execute an EPROM-resident 
error routine that would 
retract the cutting tool, turn off the other machinery, 
and trigger 
an alarm. The lathe could then be re- 
started with a minimum of downtime. 
Besides most machine-control applications, parity 
error 
detection 
is usually sufficient for laboratory 


automation, 
communications, 
and disk-based 
small 
data-processing 
applications. The common feature for 
these applications is that if a memory error can be 
detected 
immediately, 
the impact on the system is 
small; restarting 
the system is relatively easy. Parity 
is also the uSl!al fall-back solution for applications 
where the consequences 
of an undetected 
memory 
error and the error rate combine to make unprotected 
memory impractical. Though it will cause the system 
eJ;"rorrate to increase slightly, parity can limit the 
consequences ofa failure to the point ofbeing the most 
cost-effective solution. 
Thanks to 64-k RAMs, the maximum memory size 
that can be implemented 
with parity has increased. 


With 16-k RAM technology, the capacity limit was 
around 128kbytes. Beyond this capacity, the number 
ofcomponents required reduced 16-kRAM-based sys- 
tem MTBFs below acceptable limits for most applica- 
tions. Today, many microcomputer and minicomputer 
manufacturers 
and add-in memory vendors are pro- 
ducing 256- and 512-kbyte parity boards with 64-k 
RAMs and are achieving MTBFs comparable to older 
16-k RAM-based 64-k and 128-kbyte designs. 
The ability 
to detect 
single-bit 
errors 
will not 
provide adequate memory protection in applications 
where the loss of RAM data is intolerable, 
where the 
consequences of stopping the microcomputer, even in 
a controlled fashion, are prohibitively 
expensive, or 
where the memory is so large that the device count, 
even with 64-k RAMs, produces an unacceptably low 
MTBF. 


In all these applications, the system being controlled 
and monitored by the microcomputer will continue to 
operate whether or not the computer is controlling it. 
In these critical situations, 
reliability is of primary 
importance 
and the cost of using 
ECC-protected 
memory is more than offset by the up to two-orders- 
of-magnitude increase in memory system MTBF. 


ECC is also desirable 
for almost all applications 
requiring more than 512 kbytes of RAM (Fig. 4). The 
MTBF of a 512-kbyte memory with parity is about 16 
months of operation. If the system-rnns eight hours a 
day, the MTBF will be almost four calendar years, 
which is acceptable for many but not all noncritical 
applications. Above 512 kbytes, the MTBF of parity 
memory quickly drops below one year and a I-Mbyte 
memory will have an MTBF ofless than eight months. 
For these 
large 
systems, 
which are appearing 
in 
greater 
numbers, 
ECC-protected 
memory is stan- 
dard in almost all cases. 0 
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iSBX™ 275 


VIDEO GRAPHICS CONTROLLER 


• Complete 
video graphics 
display 


controller 
on an iSBX™ 
MULTIMODULE™ board 


• Interfaces 
to either black and white or 


color raster scan display 
monitors 


• 50 Hz or 60 Hz frame rate operation 


• On·board refresh memory supports 


512 x 512 black and white or 256 x 256 
eight color display 
resolution 


• High level drawing 
commands 
include 


line, arc, circle, 
rectangle, 
character, 


area fill, pan and scroll 
' 


• Includes 
Intel's 
82720 Graphic 
Display 


Controller 


• Compatible 
with industry 
standard 


iSBX™ bus interface 


The iSBX 275 Video Graphics 
Controller 
(VGC) allows 
the user to add high level video display 
capability 
to 
his/her computer 
system 
with 
minimal 
cost and effort. 
The iSBX 275 module 
provides 
a completely 
self- 


contained 
bit-mapped 
graphics 
subsystem 
on a 3" x 7" iSBX MULTI MODULE board. This same subsystem 
supports 
either 
black and white or eight color displays. 


In addition, 
iSBX 275 VGC off-loads 
the system 
CPU from many of the graphics 
drawing 
functions. 
Under 


the control 
of the Intel 82720 Graphics 
Display Controller 
(GDC), the iSBX 275 board directly 
supports 
high 
level drawing commands 
which includes 
lines, arcs, circles, 
rectangles, 
characters, 
area fill, pan and scroll. 


The iSBX 275 MUL TIMODULE 
board is compatible 
with any computer 
board or system 
product 
supporting 


the industry 
standard 
iSBX bus; this includes 
most board and system products 
from Intel. Applications 
for 


the 
iSBX 275 VGC include 
video 
displays 
for industrial 
operator 
stations, 
engineering 
work 
stations, 


videotex, 
business 
presentation 
systems 
and other information 
display 
systems. 


The follOWing are trademarks 
of Intel Corporation 
and may be used only to describe 
Intel products: 
Intet, ICE, IRMX, ISSC, iS8X, iSXM, MULTIBUS, 
MULTICHANNEL, 
MUl TlMODULE 


and iCS. Intel Corporation 
assumes 
no responSibility 
for the use at any circuitry 
other than circuitry 
embodied 
in an Intel product. 
No olher circuit 
patenllicenses 
are implied. 
© lNTELCQAPORATION, 
1982 
May, 1982 


7-1 
Order 
Number: 
210506·001 


iSBX™ Interface 


The iSBX 275 VGC communicates 
with 
the host 


board 
through 
the 
iSBX bus. The iSBX bus is a 


standard 
I/O expansion 
bus interface 
(mechanical 


and electrical) 
for any microprocessor 
system. The 


iSBX standard 
interface 
allows 
system 
designers 


to 
optionally 
add 
incremental 
I/O functionality 


after the host microprocessor 
architecture 
is com- 


plete. 
In the case of the iSBX 275 VGC, the host 


board passes 
commands, 
data and status 
to and 


from the 82720 controller 
via two iSBX bus I/O ports. 


The software 
interface 
consists 
of a series of high 


level commands 
passed 
to the 82720 controller. 
Table 
1 contains 
a summary 
of 82720 software 


commands. 


CRT Controller 


The Intel 82720 is an intelligent 
graphics 
controller 


designed 
to be the heart of a raster-scan 
computer 


graphics 
display 
system. 
The 82720 performs 
all 


the basic timing 
needed to generate the raster dis- 
play and manage the display 
memory. 
In addition, 
the 82720 supports 
several high level graphics 
fig- 
ure drawing 
functions. 


Table 2 lists several CRT vendors compatible 
with 


the iSBX 275 VGC. 


Display Screen 


The 
iSBX 275 VGC contains 
32K bytes 
of 
high 


speed 
display 
memory, 
all of which 
is under the 


control 
of the 82720. The 82720 takes care of both 


writing 
and reading 
data to and from 
the screen 


and refreshing 
the screen. 


The on-board 
display 
memory 
is organized 
as 16K 


words 
of 16·bits each. The 82720 reads or writes 


16-bits of display 
data at a time. When displaying, 


the 82720 starts 
at the top left hand corner 
of the 


screen 
and sequences 
down 
the 
screen 
toward 


the bottom 
right hand corner. 


In B&W mode all 16K, 16-bit words are treated as a 
contiguous 
block of memory, 
where a logical 
"1" 


in memory 
is displayed 
as an illuminated 
pixel. 


. In the color 
mode, three 
color 
planes, 
Red, Blue 


and Green, exist 
sequentially 
in memory 
but are 


displayed 
simultaneously. 
Each plane consists 
of 


4K, 16·bit words 
where a logical 
"1" 
in a plane il- 


luminates 
the corresponding 
color in that particu- 


lar pixel. 


Table 
1. 82720 Command 
Summary 
CRT Interface 


The iSBX 275 VGC will 
interface 
to many B&W and 


RGB (Red, Green and Blue) color 
display 
monitors. 


For B&W 
monitors, 
the 
iSBX 
275 board 
provides 


TTl 
level 
signals 
for 
video, 
vertical 
sync 
and 


horizontal 
sync 
or combined 
sync. 
When 
operat· 


ing in the 
color 
mode, 
the 
iSBX 275 module 
pro· 


vides TTl 
level 75 ohm line drivers 
for Red, Green, 


and 
Blue 
Video 
and a combined 
sync 
allowing 
8 


different 
colors 
to be displayed. 


Composite 
video 
is not provided 
on the iSBX 275 


MUl TIMODUlE 
board; 
however, 
with 
minimal 
ex· 


ternal 
circuitry, 
composite 
video 
can 
be 
added 


(sample 
composite 
video 
circuit 
designs 
are 
in· 


eluded 
in 
the 
iSBX 
275 
Hardware 
Reference 


Manual). 


Video 
Control 
Commands 


RESET: 
Resets the GDC to its idle state. 


SYNC: 
Specifies 
the video display format. 


CCHAR: 
Specifies 
the cursor 
and character 
row 


heights. 


Display 
Control 
Commands 


START: 
Ends idle mode and unblanks the display. 


BCTRl: 
Controls 
the blanking 
and unblanking 
of 


the display. 


ZOOM: 
Specifies zoom factors for graphics char· 
acter writing. 


CURS: 
Sets the position 
of the cursor in display 


memory. 


PRAM: 
Defines starting addresses and lengths of 
the display areas and specifies 
the eight 


bytes for the graphics character. 


PITCH: 
Specifies the width of the X dimension 
of 


display memory. 


Drawing 
Control 
Commands 


WDAT: 
Writes 
data words or bytes into display 
memory. 


MASK: 
Sets the mask register contents. 


FIGS: 
Specifies 
the parameters for the drawing 


processor. 


FIGD: 
Draws the figure as specified above. 


GCHRD: 
Draws the graphics character into display 
memory. 


Data Read Commands 


RDAT: 
Reads data words or bytes from display 
memory. 


CURD: 
Reads the cursor position. 


lPRD: 
Reads the light pen address. 


Table 2. CRT's (B&W and Color)' 


Type 
Vendor 
Model 
# 


B&W 
Ball Brothers 
TTl120 


Motorola 
M3570 


TSD 
MDC-15 


Color 
Ball Brothers 
7·015-0131 
lOT 
19AC 


CONRAC 
5711C13 


HITACHI 
HM-2719/2713, 
HM-1719/1713 
NEC 
1202DH 


MITSUBISHI 
C-3419 


'NOTE: This in no way constitutes an endorsement by Intel 
Corporation of these companies' products. 


Light Pen Interface 


Light 
pen I/O devices 
may be directly 
interfaced 
to 


the iSBX 275 VGC. A light 
pen input 
or "hit" 
is trig· 


gered on the rising 
edge of the light 
pen signal 
and 


is 
indicated 
by 
a status 
bit 
in 
the 
82720. 
The 


memory 
address 
of the 
light 
pen 
hit 
is obtained 


with 
a lPF3D (Light 
Pen Read) command. 


Table 
3 lists 
a light 
pen vendor 
whose 
product 
in· 


terfaces 
to the iSBX 275 VGC. 


Table 3. Light 
Pens' 


Vendor 


Information 
Control Co. 


Model # 


lP-700 


1 NOTE:This in no way constitutes an endorsement by Intel 


Corporation of this company's products. 


Figure 
2. The iSBxn, 
275 VGC Interfaces 
to a 


User·Supplied 
Video 
CRT and Light 
Pen 


inter 


Controller Characteristics 


DISPLAY 
RESOLUTION 


Black and White - 
nominal 512 x 512x 
1, interlaced 


Color - 
nominal 
256 x 256 x 3, non-interlaced 


CRT OUTPUTS 


Black 
and 
White 
- 
TTL 
level 
Video, 
HSYNC, 


VSYNC or CSYNC; maximum 
dot rate 13 MHz 


Color - 
TTL level, 75 ohm line drivers for RGB and 


combined 
sync provide 
8 different 
display 
colors 


with a 9.75 MHz maximum 
dot rate 


50 Hz or 60 Hz via programmable 
option 
(non- 


interlaced) 


VIDEO 
CONTROL 


Pan_and user selectable 
display 
and background 
color 


Lines, 
arcs, 
circles, 
rectangles, 
characters 
and 
area fill 


Black and White 
- 
Most video display 
monitors 


with a TTL interface 
and a minimum 
bandwidth 
of 


12 MHz 


Color - 
Most video display 
monitors 
with 
a TTL 
interface 
and a minimum 
bandwidth 
of 6 MHz 


TTL level pulse, 
maximum 
50 ns rise time, 
mini- 


mum 1.4 p.Shold time 


Compatibility 


CPU 


Any iSBC single board computer 
or I/O board com- 
patible 
with the MULTIBUS system 
bus and imple- 
menting 
the iSBX bus and connector 


Physical Characteristics 


Width 
- 
3.08 inches 
(7.82 cm) 


Height 
- 
0.8 inches (2.05 cm) 


Length - 
7.5 inches (19.05 cm) 


Shipping 
Weight 
- 
0.5 pounds 
(0.175 Kg) 


Mounting 
- 
Occupies 
one 
double-wide 
iSBX 


MULTIMODULE 
position 
on 
boards; 
increases 
board height (host plus iSBX board) to 1.14 inches 
(2.90 cm) 


Electrical Characteristics 


Power Requirements 
- 
+ 5 Vdc @ 1.5A 


Environmental Characteristics 


Temperature 
- 
0° to 55°C (operating); 
- 55°C to 


+ 85°C (non-operating) 


Humidity 
- 
Up to 90% 
relative 
humidity 
without 
condensation 
(operating); 
all conditions 
without 


condensation 
or frost (non-operating) 


Equipment Supplied 


iSBX 275 VGC Controller 


Reference 
Schematic 
- 
Cabling 
and connectors 


from the VGC controller 
to the CRT and light 
pen 


are not supplied 
with the controller. 
Cables can be 


fabricated 
with 
commercially 
available 
cable and 
connectors 
as described 
in the iSBX 275 Hardware 


Reference 
Manual. 


Reference Manual 


144829·001 - 
iSBX 275 Video Graphics Display Con- 


troller Hardware Reference Manual (NOT SUPPLIED) 


Reference 
manuals 
may be ordered from any Intel 
sales representative, 
distributor 
office 
or from Intel 
Literature 
Department, 
3065 Bowers Avenue, Santa 


Clara, CA 95051. 


Part Number 
Description 


SBX 275 
Video Graphics 
Display Controller 
MULTIMODULE 
Board 


iSBX™ 
270 
VIDEO DISPLAY CONTROLLER 


• Complete 
video display 
controller 
on a 


double-wide 
iSBX™ MULTIMODULE™ 


board 


• Keyboard 
and light 
pen interface 


provided 
on-board 


• Interfaces 
to either 
black and white or 
color display 
monitors 


• Displays 
7 x 9, 5 x 7 or 6 x 8 character 


fonts 


• Provides 
cursor control, 
reverse video, 


blinking, 
underline, 
highlight 
and page 


or scroll 
mode 


• High level software 
interface 
via a 
pre-programmed 
8041A UPI 


• Compatible 
with all 8/16 bit iSBC™ 


boards which 
support 
the Intel iSBX™ 


bus 


• Interchangeable 
character 
fonts 
avatlable 
in EPROM 
• Graphics 
capability 
via pre-defined 


graphic 
character 
fonts 


The iSBX 270 Video Display Controller 
(VDC) is a complete 
video controller 
on a standard 
double wide Intel 


iSBX MULTIMODULE 
board. Providing 
either black and white 
(B&W) or eight-color 
displays, 
the iSBX 270 
VDC brings 
alphanumeric 
video control 
to the iSBX bus. Any computer 
board or system 
supporting 
the 
Intel iSBX MUL TIMODULE 
bus is compatible 
with the iSBX 270 VDC, including 
most board and system 
pro- 


ducts 
from 
Intel. 
Additionally. 
the 
iSBX 270 VDC supports 
keyboard 
ana light 
pen I/O on-board; 
this 


simplifies 
the design 
of intelligent 
terminals. 


The iSBX 270 module allows 
the user to add high level video display 
capability 
to his/her computer 
system 
with a minimal 
cost and effort. 
Typical 
applications 
for the iSBX 270 VDC include 
video displays 
for in· 


dustrial 
operator 
stations, 
word 
processing 
systems, 
data base management 
products 
and many other 


uses. 


The following 
are trademarks 
of Intel 
Corporation 
and may be used only 
to describe 
Inlel 
products: 
Intel, 
CREDIT, 
Index, 
I051te, Intellec, 
library Manager. 
Megachassis, 


Micromap, 
MULTI BUS. PROMPT, 
UPI, .••Scope, 
Promware, 
MeS, ICE, IRMX, isac, 
iSBX, 
MUlTlMODULE 
and ieS. tntel Corporation 
assumes 
no responsibility 
for the use of any 


circuitry 
other 
than circuitry 
embodied 
in an tntel prOduct. 
No other circuit 
patent 
licenses 
are implied. 


inter 


iSBX™ Interface 


The iSBX 270 VDC interfaces to the Intel iSBX bus 
via the 8041A Universal Peripheral Interface (UPI) 
Microcomputer. The 8041A, under firmware con- 
trol, provides communication 
between the base 


board and the iSBX 270 controller circuitry via the 
iSBX data and control lines. Datamay be displayed 
immediately following power up, using default ini- 
tialization provided by the 8041A UPI. In addition, 
eight high-level commands are provided by the 
iSBX 270 firmware; these eight commands are 
used to alter the default initialization of the con· 
troller and determine status. Following initializa- 
tion, characters are displayed on the CRT by sim- 
ply writing to the proper 1/0 port. 


The iSBX 270 VDCwill interface to many B&W and 
RGB color display monitors. For B&W monitors, 
the iSBX 270 board provides TIl 
level signals for 


video, vertical sync and horizontal sync. Addi- 
tionally, in B&W, two levels of intensity (normal 
and highlight) are supported under program con- 
trol. 


CONTROL 
ADDRESS 
BUS 


When operating in the color mode, the iSBX 270 
module provides TTl level 75 ohm line drivers for 
Red, Green, and Blue Video and sync allowing 8 
different colors to be displayed. 


Composite video is not provided on the iSBX 270 
MULTIMODULE board; however, with minimal ex- 
ternal circuitry, composite video can be added (cir- 
cuit design available; contact the local Intel Sales 
Office for details). 


Table 1 lists several CRTvendors compatible with 
the iSBX 270 VDC. 


TYPE 
VENDOR 
MODEL 
# 


B&W 
Ball Brothers 
TTL 120, TV 120, TV 50 


Motorola 
M3570 


TSD 
MDC-15 


ELSTON 
DM30-12BO-51-A04 


Color 
Ball Brothers 
7-015-0131 


IDT 
19AC 


CONRAC 
5711C13 


NEC 
1202DH 


MITSUBISHI 
C-3419 


'NOTE: 
This in no way constitutes 
an endorsement 
by Intei 


Corporation 
of these companies' 
products. The com- 


panies listed are known to provide products compati- 
ble with the is ax 270 board. 


) 


inter 


The CRT Controller 
performs 
all timing 
and data 
buffering 
functions 
for the CRT. The iSBX 270 VDC 
uses the Intel 8275 CRT Controller 
(for additional 
details 
refer to the 8275 data sheet available 
from 
Intel). 


Screen Refresh 


The iSBX 270 VDC contains 
4K bytes of high speed 
static 
RAM, as well 
as a high 
speed 
DMA con· 
troller 
(8237A). The 8237A, under the control 
of the 
8041A UPI, takes care of both writing 
data to the 
screen and refreshing 
the screen. 


Character Generation 


The 
character 
fonts 
(128 characters, 
including 
alphabetic, 
numeric, 
and special 
characters) 
that 
are displayed 
on the CRT are stored 
in EPROM. 


The need may arise to display 
different 
character 
fonts, 
i.e., those 
used in international 
systems 
or 
custom 
symbols 
which 
are application 
specific. 
With the iSBX 270 VDC the user may modify any or 
all of the character 
fonts by simply 
reprogramming 
the 
EPROM. 
In addition, 
the 
user 
may utilize 
a 
larger EPROM to obtain 
up to 256 characters. 


Keyboard Interface 


The iSBX 270 VDC also interfaces 
to a keyboard 
I/O device via the J1 edge connector. 
The keyboard 
interface 
of the iSBX 270 VDC accepts 
up to eight 
TTL parallel 
data lines and one TTL strobe, 
either 
positive 
or negative. 
Keyboard 
input 
is indicated 
by a status 
bit in the 8041A and/or an interrupt. 
In 
addition, 
control 
lines 
are 
provided 
for 
visual 
and/or audible 
indicators. 


Table 
2 lists 
several 
keyboards 
that 
interface 
to 


the iSBX 270 VDC. 


VENDOR 
MODEL 
# 


Advanced Input Devices 
SK-067 
Cherry 
B70-05AB 
Cherry 
CB80-07AA 
Chomerics 
AN26109/AE26203 


Cortron 
35-500014 


Keytronic 
L1648 
Keytronic 
L1660 
Keytronic 
L1674-03 
Keytronic 
L1752 
Microswitch 
66SD6-7 
Microswitch 
87SD30·8 


'NOTE: This in no way constitutes 
an endorsement by Intel 


Corporation of these companies' products. The com· 
panies listed are known to provide products compati· 
ble with the iSBX 270 board. 


Light Pen Interface 


Light pen I/O devices 
may be directly 
interfaced 
to 


the iSBX 270 VDC. A light 
pen hit is triggered 
on 


the rising 
edge of the light 
pen signal 
and is in- 


dicated 
by a status 
bit in the UPI 8041A and/or an 


interrupt. 


Table 3 lists a light 
pen vendor whose 
product 
in· 


terfaces 
to the iSBX 270 VDC. 


Table 3. Light Pens' 


VENDOR 
MODEL 
# 


LP-700 


'NOTE: This in no way constitutes 
an endorsement by Intel 


Corporation of this company's products. The company 
listed is known to provide products compatible with 
the iSaX 270 board. 


inter 


Programmable 
to a maximum 
of 35 rows x 80 col- 
umns of characters. 


CRT OUTPUTS 


B&W - 
TIL 
level HSYNC, VSYNC, Video. 


Color - 
TIL 
level, 75 ohm line drivers for RGB and 
combined 
sync provide 
8 different 
display 
colors. 


5 x 7, 7 x 9 or 6 x 8 jumperable 
with 
appropriate 
crystal. 
Character 
generator 
uses 
2716 EPROM. 


Also compatible 
with 2732A EPROM's. For genera- 
tion of special 
fonts, 
please refer to iSBX 270 VDC 
Hardware 
Reference 
Manual. 


Reverse video, 
blinking, 
underline, 
highlight, 
cur- 
sor control 
and page or scroll 
mode. 


Most video display 
monitors 
with a 10 MHz band- 


width 
or better. 


TIL 
level pulse, 
maximum 
50 ns rise time, 
mini- 
mum 100 ns hold time. 


Compatibility 


CPU 


Any iSBC single 
board computer 
or 1/0 board com- 
patible 
with 
the 
MUL TIBUS system 
bus and im- 
plementing 
the iSBX bus and connector. 


Width 
- 
3.08 inches 
(7.82 cm) 


Height 
- 
0.8 inches 
(2.05 cm) 


Length 
- 
7.5 inches 
(19.05 cm) 


Shipping 
Weight 
- 
0.5 pounds 
(0.175 Kg) 


Mounting 
- 
Occupies 
one 
double-wide 
iSBX 
MULTI MODULE 
position 
on 
boards; 
increases 
board height (host plus iSBX board) to 1.14 inches 
(2.90 cm). 


Electrical Characteristics 


Temperature 
- 
O°C to 55°C (operating); 
- 55°C to 
+ 85°C (non-operating). 


Humidity 
- 
Up to 90% relative 
humidity 
without 
condensation 
(operating); 
all conditions 
without 
condensation 
or frost 
(non-operating). 


iSBX 270 VDC Controller 
Reference 
Schematic 


Cabling 
and connectors 
from 
the VDC controller 
to the CRT, keyboard 
and light 
pen are not sup- 


plied with the controller. 
Cables can be fabricated 
with commercially 
available 
cable and connectors 
as described 
in the iSBX 270 Hardware 
Reference 
Manual. 


143444·001 - 
iSBX 270 Video 
Display 
Controller 
Hardware 
Reference 
Manual (NOT SUPPLIED). 


Reference 
manuals 
may be ordered 
from any Intel 
sales 
representative, 
distributor 
office 
or from 
Intel Literature 
Department, 
3065 Bowers Avenue, 


Santa Clara, CA 95051. 


Part Number 
Description 


SBX 270 
Video 
Display 
Controller 
MULTIMODULE 
Board 


iSBC™ 220 
SMD DISK CONTROLLER 


• Controls 
up to four SMD interface 
compatible 
disk drives 


• Compatible 
with all iS~CTM80, 
iSBC™ 88, and iSBC™ 86 Single Board 
Computers 


• Intel@8089 I/O Processor 
provides 
two 
high speed DMA channels 
as well as 
controller 
intelligence 


• Software 
drivers available 
for 
iRMX™ 86 and iRMX™ 88 operating 
systems 


• On-board diagnostic 
and ECC 


• Full sector 
buffering 
on-board 


• Capable of addressing 
1 MB of system 


memory 


• SMD interface 
available 
on 14" 
Winchester, 
CMD, SMD and large 
fixed-media 
drives 


The iSBC 220 SMD Disk Controller 
brings very large mass storage capabilities 
to any iSBC 80, iSBC 88, or 


iSBC 86 MUL T1BUS system. 
The controller 
will interface 
to any disk drive conforming 
to the industry 
stan- 


dard SMD interface. 
Using simplified 
cable connections, 
up to four drives may be connected 
to the iSBC 


220 Controller 
Board to give a total 
maximum 
capacity 
of 2.4 gigabytes. 
The Intel 8089 I/O Processor 
sim- 


plifies 
programming 
through 
the use of memory-based 
parameter 
blocks. 
A linked 
list technique 
allows 


the user to perform 
multiple 
disk operations. 


The 
foHowing 
are trademarks 
of Intel 
Corporation 
and 
may 
be used 
only 
to describe 
Intel 
products: 
CREDIT, 
Index, 
Intel, 
Inslte, 
Intellec, 
library 
Manager, 
Megachassis, 


Micromap. 
MULTIBUS, 
PROMPT, 
UPI, ~Scope, 
Promwar8, 
MeS, 
ICE, iRMX, 
iSSe, 
iSBX, 
MUlTIMODUlE 
and iCS, and the combination 
of MeS. 
ICE, iSSe, 
iSBX or leS, 
and a 
numerical 
suffix. 
Intel 
Corporation 
assumes 
no responsibility 
for the use of any circuitry 
other 
than circuitry 
embodied 
in an Intel 
product. 
No other 
circuit 
patent 
licenses 
are 


implied. 
© INTEl 
CORPORATION, 
1980 
7-9 
November 
1980 


AFN-Q179-CA 
1.3283 


Full On· Board Buffer 


The iSBC 220 SMD Controller 
contains 
enough on- 


board RAM for one full sector 
buffering. 
The con- 
troller 
is designed 
to make use of this buffer 
in all 


transfers. 
The 
on-board 
sector 
buffer 
prevents 


data overrun 
errors and allows 
the iSBC 220 SMD 


Controller 
to 
occupy 
any 
priority 
slot 
on 
the 


MULTIBUS. 


ECC 


High data integrity 
is provided 
by on-board 
Error 


Checking 
Code (ECG) logic. 
When writing 
sector 


10 or data fields, 
a 32-bit Fire code, for burst error 


correction, 
is appended 
to the field 
by the con- 


troller. 
During a Read operation, 
the same logic re- 
genera,tes the ECC polynomial 
and compares 
this 


second 
polynomial 
to 
the 
appended 
ECC. The 
ECC logic 
can detect 
an erroneous 
data burst 
up 


to 32 bits 
in length 
and using 
an 8089 alrogithm 


can correct 
an erroneous 
burst 
up to 11 bits 
in 


length. 


SMD Interface 


High 
speed, 
reliable 
data 
transfers 
are a major 


benefit 
of using the SMD interface. 
A data transfer 


rate of 1.2 MB is accomplished 
by using separate 


(radial) differential 
data line cabling 
for each drive. 


Control 
signals 
are daisy-chained 
from 
drive 
to 


drive. 


Defective Track Handling 


When a track 
is deemed 
defective, 
the host 
pro- 


cessor 
reformats 
the track, 
giving 
it a defective 


track 
code 
and 
enters 
the 
address 
of the 
next 


available 
alternate 
track. 
When the controller 
ac- 


cesses 
a track 
previously 
marked 
defective, 
the. 


controller 
automatically 
seeks 
to 
the 
assigned 


alternate 
track. The alternate 
track 
seek is totally 


automatic 
and invisible 
to the user. 
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Compatibility 


CPU - 
Any iSBC MUL TIBUS computer 
or system 


mainframe 


Disk Drive - 
Any SMD interface-compatible 
disk 


drive 


Equipment Supplied 


iSBC 220 SMD Disk Controller 


Reference 
schematic 


Controller-to-drive 
cabling 
and connectors 
are not 


supplied 
with 
the controller. 
Cables 
can be fabri- 


cated 
with 
flat 
cable 
and commercially-available 


connectors 
as described 
in the 
iSBC 
220 SMD 


Disk Controller 
Hardware 
Reference 
Manual. 


Physical Characteristics 


Width 
- 
6.75 in. (17.15 cm) 


Height 
- 
0.5 in. (1.27 cm) 


Length 
- 
12.0 in. (30.48 cm) 


Shipping 
Weight 
- 
19 oz (0.54 kg) 


Mounting 
- 
Occupies 
one slot 
of iSBC system 


chassis 
or cardcage/backplane 


Electrical Characteristics 


Power Requirements 
+ 5 VDC @ 3.25A max 


- 5 VDC @ 0.75A max 1 


Note 1: On·board 
voltage 
regUlator 
allows 
optional 
-12 
VDC 


usage from MULTIBUS. 


Data Organization and Capacity 


Bytes per Sector"! - 
128 256 521 
1024 


Sectors 
per Track2 
- 
108 64 35 
18 


Note 2: Software 
selectable. 


Disk (spindle) 
Speed 


Tracks 
per Surface 


Head 
Positioning 


3600 
rpm 


823 


Closed 
loop 
servo 
type, 
track 


following 


Track 
to Track 


Average 
Maximum 


6ms 
30 ms 
55 ms 


Data 
Transfer 
Rate 


Storage 
Capacity 


1.2 megabytes/second 


12 to 2.4 gigabytes 


Temperature 
- 
O·C to 55·C 
(operating); 
- 55·C 
to 
+ 85·C 
(non-operating) 


Humidity 
- 
Up to 90% 
relative 
numidity 
without 
condensation 
(operating); 
all 
conditions 
without 
condensation 
or frost 
(non-operating) 


Reference Manual 


121597·001 - 
iSBC 220 SMD Disk Controller 
Hard- 
ware 
Reference 
Manual 
(NOT SUPPLIED) 


Reference 
manuals 
may be ordered 
from 
any Intel 
sales 
representative, 
distributor 
office, 
or 
from 
Intel 
Literature 
Department, 
3065 Bowe(s 
Avenue, 
Santa 
Clara, 
CA 95051. 


Part Number 


SBC 220 
Description 


SMD 
Disk Controller 


iSBX 218 
FLEXIBLE DISK CONTROLLER 


• iSBX MULTIMODULE 
controller 
provides flexibility at low cost 
• Phase lock loop data separator assures 
maximum data integrity 


• Controls most single and double 
density diskette drives 
• Read and write on single or multiple 
sectors 


• User-programmable 
drive parameters 
allow wide choice of drives 


The Intel 
iSBX 218 Flexible 
Disk Controller 
is a double-wide 
iSBX board diskette 
controller 
capable 
of 


supporting 
virtually 
any soft-sectored, 
double density 
or single 
density 
diskette 
drive. 
The standard 


controller 
can control 
up to four drives with 
up to eight 
surfaces. 
In addition 
to the standard 
IBM 3740 


formats 
and IBM System 34 formats, 
the controller 
supports 
sector 
lengths 
of up to 8192 bytes. The iSBX 


218 board's 
wide 
range 
of drive 
compatibility 
is achieved 
without 
compromising 
performance. 
The 


operating 
characteristics 
are specified 
under user program 
control. 
The controller 
can read, write, verify, 


and search either single or multiple 
sectors. 


FUNCTIONAL 
DESCRIPTION 


Intel's 
8272 Floppy 
Disk Controller 
(FOG) chip 
is 


the 
heart 
of the 
iSBX 218 Controller. 
On-board 


data 
separation 
logic 
performs 
standard 
MFM 


(double density) and FM (single density) 
encoding 


and decoding, 
eliminating 
the need for external 


separation 
circuitry 
at the drive. 
Data transfers 


between 
the controller 
and memory 
are managed 


by the intelligent 
device 
(usually 
an Intel 8-bit or 


16-bit 
CPU 
chip) 
on 
the 
host 
board. 
A 
block 


diagram 
of the iSBX 218 Controller 
is .shown 
in 


Figure 1. 


Because 
the 
iSBX 218 Controller 
has universal 


drive compatibility, 
it can be used to control 
vir- 
tually 
any standard- 
or mini-sized 
diskette 
drive. 


Moreover, 
the iSBX 218 Controller 
fully 
supports 


the 
iSBX bus and can be used 
with 
any single 


board 
computer 
which 
furnishes 
this 
bus. 


Because 
the 
iSBX 
218 
Controller 
is 
program- 
mable, its performance 
is not compromised 
by its 


universal 
drive 
compatibility. 
The track-to-track 


access, 
head-load, 
and 
head-unload 
character- 
istics 
of the 
selected 
drive 
model 
are program 


specified. 
Data may be organized 
in sectors 
up 


to 8192 bytes in length. 


Interface Characteristics 


The standard 
iSBX 218 Controller 
includes 
an Intel 


8272 Floppy 
Disk Controller 
chip which 
supports 


up to four drives, single or double sided. 


SIMPLIFIED 
INTERFACE-The 
cables 
between 
the iSBX 218 Controller 
and the drivels) 
may be 


low cost, flat ribbon 
cable with 
mass termination 


connectors. 
The 
mechanical 
interface 
to 
the 


board is a right-angle 
header with locking 
tabs for 


security 
of connection. 


PROGRAMMING - 
The powerful 
8272 FDC circuit 


is capable of executing 
high-level 
commands 
that 


simplify 
system software 
development. 
The device 


can read and write 
both single 
and multiple 
sec- 


tors. CRC characters 
are generated 
and checked 


automatically. 
Recording 
density 
is selected 
at 


each Read and Write to support the industry 
stand- 


ard technique 
of recording 
basic 
media 
informa- 


tion on Track 0 of Side 0 in single density, 
and then 


switching 
to 
double 
density 
(if 
necessary) 
for 


operations 
on other tracks. 
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PROGRAM INITIATION-All 
diskette 
operations 


are initiated 
by standard 
iSBX bus input/output 


(I/O) operations 
through 
the host 
iSBC single 


board computer. 
System software first initializes 


the' controller 
with the operating 
characteristics 


of the selected drive. The diskette is then format- 
ted under program control. Data transfers occur in 
response to commands output by the CPU. 


DATA TRANSFER-Once 
a diskette 
transfer 


operation 
has been initiated, 
the controller 
will 


require 
a data transfer 
every 13 microseconds 


(double density) or 26 microseconds 
(single den- 


sity). Most CPUs will operate in a polled mode, 
checking controller 
status and transferring 
bytes 


when the controller 
is ready. Boards utilizing 
the 
Intel 8080 chip, such as the iSBC 80/10B board, 
will be restricted to single density operation with 
the iSBX 218 Controller, 
due to these speed re- 


quirements. 
A programming 
example illustrating 


the iSBC 80/10B handler is contained in the Hard- 
ware Reference Manual. 


Compatibility 


CPU-Any 
iSBC single 
board computer 
or I/O 


board compatible 
with the MULTIBUS system 


bus and implementing 
the iSBX bus and con- 
necfor. 


Devices-Double 
or single density standard (8") 


and mini (51/.1") flexible disk drives. The drives 
may be single or double sided. Drives known 
to be compatible are: 


Standard (8") 
Mini (51/.1") 


Caldisk 
143M 
Shugart 
450/400 


Remex 
RFD4000 
Micropolis 
1015-IV 


Memorex 550 
Pertec 
250 


MFE 
700 
Siemens 
200-5 


Siemens 
FDD200-8 
Tandon 
TM-100 


Shugart 
SA850/800 
CDC 
9409 


Pertec 
FD650 
MPI 
51/52/91/92 


CDC 
9406-3 


Diskette-Unformatted 
IBM Diskette 1 (or equiv- 


alent 
single-sided 
media); unformatted 
IBM 


Diskette 20 (or equivalent double-sided). 


Equipment Supplied 
iSBX 218 Controller 
Reference Schematic 
Controller-to-drive 
cabling and connectors are not 
,supplied with the controller. 
Cables can be fabri- 


cated with flat cable and commercially-available 
connectors 
as described 
in the iSBX 218 Hard- 


ware Reference Manual. 
Nylon Mounting 
Bolts 


Physical Characteristics 


Width-2.85 
inches (7.24 cm) 
Height-0.5 
inches (1.27 cm) 
Length-7.S 
inches (19.05 cm) 
Shipping Weight-1 
pound (0.46 Kg) 


Mounting-Occupies 
one double-wide iSBX MUL- 


TIMODULE 
position 
on 
boards; 
increases 


board height (host plus iSBX board) to 1.13 
inches (2.87 cm). 


Double Density 
Single Density 


IBM System 34 
Non·IBM 
IBM System 3740 
Non·IBM 


BytesperSector 
256 
512 
1024 
2048 
4096 
8192 
128 
256 
512 
1024 
2048 
4096 


SectorsperTrack 
26 
15 
8 
4 
2 
1 
26 
15 
8 
4 
2 
1 


Tracksper Diskette 
77 
256 
77 
256 


BytesperDiskette 
512,512 
256,256 


(Formatted,per 
(256bytes/sector) 
(128byte/sector) 
diskette surface) 
591,360 
630,784 
295,680 
315,392 
(512bytes/sector) 
(256bytes/sector) 
630,784 
315,392 


(1024bytes/sector) 
(512bytes/sector) 


Standard Size 
Mini Size 


Double/Single Density 
Double/Single Density 


Transfer Rate (K bytes/see) 
62.5/31.25 
31.25/15.63 


Disk Speed (RPM) 
360 
300 


Step Rate Time 
1 to 16 msecltrack 
in 
2 to 32 msecltrack 
in 
(Programmable) 
1 msec increments 
2 msec increments 


Head Load Time 
2 to 256 msec in 
4 to 512 msec in 
(Programmable) 
2 msec increments 
4 msec increments 


Head Unload Time 
o to 240 msec in 
o to 480 msec in 
(Programmable) 
16 msec increments 
32 msec increments 


Electrical Characteristics 


Power Requirements- 
+ 5 VDC @ 0.81A 


Environmental Characteristics 


Temperature-O°C 
to 55°C (operating); 
- 55°C to 
+ 85°C (non-operating). 


Humidity-Up 
to 90% 
Relative 
Humidity 
without 
condensation 
(operating); 
all conditions 
with- 
out condensation 
or frost (non-operati 
ng). 


Reference Manual 


121583-001-iSBX 
218 
Flexible 
Disk 
Controller 
Hardware 
Reference 
Manual 
(NOT 
SUPPLIED). 


Reference 
manuals 
may be ordered 
from any Intel 
sales 
representative, 
distributor 
office, 
or 
from 
Intel Literature 
Department, 
3065 Bowers 
Avenue, 


Santa Clara, CA 95051. 


Part Number 
SBX218 
Description 
Flexible 
Disk Controller 


inter 


iSBX™ 217B ~·INCH TAPE DRIVE 
INTERFACE MULTIMODULE™ BOARD 


• iSBX™ MULTIMODULE™ interface 
provides tape backup capability for 
iSBC®215 Generic Winchester 
Controller 


• Configurable to interface with up to 
four Archive Sidewinder* 
compatible 
or four 3M HCD-75 compatible tape 
drives 


• + 5 volt only operation 


• Supports transfer rates of 90K, 30K or 


17K bytes per second depending on 
tape speed 


• Supported by iRMX™ 88/86 and XENIXt 


Operating Systems when used on 
iSBC®215 Generic Winchester 
Controller board 


• Implements the proposed QIC-2 
streaming tape interface standard 


The iSBX™ 217B 
Y4-lnch Tape Drive Interface 
module 
is a member 
of Intel's 
family 
of iSBX bus compatible 
MULTIMODULETM products. 
iSBX MULTI MODULE 
boards plug directly onto any iSBX bus compatible 
host board, 


offering incremental 
on-board I/O expansion. 
The module is particularly 
useful for implementing 
cartridge tape back- 
up capability 
directly on the iSBC® 215 Generic Winchester 
Disk Controller 
via DMA. The iSBX 217B board can also 
provide a low-cost tape storage interface for any Intel single board computer, with an iSBX connector, via programmed 
1/0. The iSBX 217 module 
interfaces 
with up to four Archive 
or Cipher Corporation 
streaming 
tape drives. These 
drives provide 20 or 45 megabytes 
of storage each. When used in conjunction 
with these drives and the iSBC 215 
board, the module can transfer 20 megabytes 
of data from disk to tape in about fourteen 
minutes. 
Alternatively, 
the 
iSBX 217B board can interface 
with up to four 3M Company 
HCD-75 compatible 
start/stop 
tape drives, for those 
applications 
requiring 
access to individual 
data files on tape. 


• Sidewinder 
is a trademark 
of Archive Corporation. t XENIX 
Is a trademark 
of Microsoft Corporation., 


The following 
are trademarks 
of Intel Corporation 
and may be used only to describe 
Intel products: 
Intel, ICE, 
iMMX, 
iRMX, 
iSBC, 
iSBX, 
iSXM, 
MUL TlBUS, 
MULTICHANNEL 
and MUl TrMODULE. 
Inlel Corporation 
assumes 
no responsibility 
for the use of any circuitry other than circuitry embodied 
in an Intel product 
No other circuit patenllicenses 
are implied. 
© INTEL 
CORPORATION, 
1982 


inter 


The iSBX 217B module 
implements 
an interface 
be- 
tween 
a host 
iSBC 
board 
and 
a cartridge 
1f4-inch 
magnetic 
tape drive, with a minimum 
of host software 
overhead. 
Data transfers 
may occur in either a direct 
memory access (DMA) or programmed 
I/O mode. The 
DMA mode 
is available 
only with 
host iSBC 
boards 
which 
have DMA capability. 
In both modes, 
the host 
must be able to transfer data at a rate of 90K, 30K or 17K 
bytes per second, 
depending 
on the speed of the tape 
drive. 


A command 
plus one-to-five parameter bytes are issued 
by the host iSBC board to the iSBX 217B module to in- 
itiate any tape·interface 
operation. 
Commands 
for the 
Archive 
and 3M interfaces 
are summarized 
in Table 1. 


If the function 
is a Read or a Write operation, 
the host 
must then be ready to transfer 
data a byte at a time to 
or from the module. 
In programmed 
I/O mode, with Ar- 
chive drives, the host polls the iSBX 217B status port 
to learn when the tape interface is ready forthe 
next 512 
byte data block. During the data block transfer, the host 
is interrupted 
by MWAIT/ when the interface is ready to 
transfer 
a data byte. With 3M tape drives, the host may 
be interrupted 
or use MDRQT 
to detect 
when 
the 
module 
is ready 
for the next byte transfer. 
In DMA 
mode, 
the host board 
uses the DMA Request 
signal 
(MDRQT) 
of the 
iSBX 
bus to synchronize 
the data 
transfer. At the conclusion 
of a tape operation, the iSBC 
host must read one or more of the iSBX 217B module's 
Sense Bytes to receive status information 
on the com- 
pleted operation. 
When the iSBX 217B module is used 
on the iSBC 215 Generic Winchester 
Controller 
board, 


--=----=--=---=--:--=.-=-"=-j 


I 


iSU'· 
BUS 
I 


COHN 
ECTOR 
I 
I 


these host requirements 
are fulfilled by the standard on- 
board firmware 
and are transparent 
to the user. 


Command 
Archive 
3M 
(Hex) 
Interface 
Interface 


OOH 
RESET 
1 
1 


01H 
INITIALIZE 
1 
1 


02H 
WRITE 
1 
3 
03H 
WRITE 
FILE MARK 
1 
1 


04H 
READ 
1 
3 
05H 
READ 
FILE MARK 
1 
N 


06H 
READ 
STATUS 
1 
1 
07H 
REWIND 
1 
1 


08H 
RETENTION 
1 
1 


09H 
ERASE 
TAPE 
1 
N 
OAH 
RESERVED 
N 
N 


OSH 
RESERVED 
N 
N 
OCH 
UNLOAD 
TAPE 
N 
1 
ODH 
RESERVED 
N 
N 


- 
- 
- 
13H 
RESERVED 
N 
N 
14H 
CONTINUE 
N 
1 
15H 
WRITE 
RAM 
N 
5 
16H 
READ 
MEMORY 
N 
5 
17H 
VERIFY 
N 
5 
18H 
RESERVED 
- 
- 
- 
- 
- 
3FH 
RESERVED 
- 
- 
40H 
START 
OF TRANSFER 
1 
1 


41H 
RESERVED 
- 
- 
- 
- 
- 


7FH 
RESERVED 
- 
- 
80H 
END OF TRANSFER 
1 
1 


Table 
1. 
Commands 
required 
by Archive 
and 
3M 
tape drives. 
Number 
indicates 
the param- 


eter 
bytes 
required 
by the 
command. 
N 
indicates 
the command 
is not supported 
by the drive. 


Compatibility 


Host - 
Any iSBC single board computer 
or peripheral 


controller 
with 
an iSBX 
connector. 
The 
iSBC 
215 


Generic Winchester 
Controller 
includes on-board firm- 


ware to support 
the iSBX 217B under either the iRMX 


88/86 or XENIX Operating 
Systems. 
The firmware 
on 


the iSBC 215A and iSBX 215B Winchester 
Controllers 


cannot 
support 
the iSBX 217B module. 


Drives - 
Any Archive Sidewinder 
or 3M HCD-75 inter- 


face compatible 
cartridge 
V4-inch magnetic 
tape drive .. 


Transfer Rate 


90K (one byte every 11 microseconds), 
30K (one byte 


every 
33 microseconds) 
or 17K (one byte every 
53 


microseconds) 
depending 
on tape drive speed. 


Equipment Supplied 


iSBX 217B Interface 
Module 


Reference 
Schematic 


Controller-to-drive 
cabling and connectors 
are not sup- 
plied. 
Cables 
can be fabricated 
with 
flat cable 
and 


commercially-available 
connectors 
as described 
in the 


iSBX 217B Hardware 
Reference 
Manual. 


Nylon mounting 
bolts 


Physical Characteristics 


Width - 
3.08 inches (7.82 cm) 


Height - 
0.809 inches (2.05 cm) 


Length - 
3.70 inches (9.40 cm) 


Shipping 
Weight - 
3.5 ounces 
(99.2 gm) 


Mounting 
- 
Occupies 
one single-wide 
iSBC 


MULTIMODULE 
position 
on boards 


Environmental Characteristics 


Temperature 
- 
O°C to 55°C 
(operating); 
- 55°C 
to 


+ 85°C (non-operating) 


Humidity 
- 
Up to 90% relative humidity 
without 
con- 


densation 
(operating); 
all conditions 
without condensa- 


tion or frost (non-operating) 


Reference Manual 


144260-001 
- 
iSBX 217B Board Hardware 
Reference 


Manual 
(NOT SUPPLIED) 


Part Number 
Description 


SBX 217B 
Cartridge 
V4-lnch Tape Drive 


Interface 


inter 


iSBC® 215 GENERIC 
WINCHESTER 
CONTROLLER 


• Controls 
up to four 51/.4",8" or 14" 
Winchester 
disk drives from over ten 
different 
vendors 


• Compatible 
with Industry 
Standard 
MULTIBUS® (IEEE 796) Interface 


• Suports 
ANSI X3T9/1226 standard 
interface 


• Software 
drivers 
available 
for 
iRMX™ 86, iRMX™ 88 and Xenix· 
Operating 
Systems 


• Intel 8089 I/O Processor 
provides 
in- 
telligent 
DMA capability 


• On-board diagnostics 
and ECC 


• Full sector 
buffering 
on-board 


• Capable of directly 
addressing 
16 MB 
of system 
memory 


• Removable 
back-up storage 
available 
through 
the iSBX™ 218 Flexible 
Disk 
Controller 
and the iSBX™ 217 1/.4"Tape 
Interface 
Module' 


Using VLSI technology, 
the iSBC 215 Generic 
Winchester 
Controller 
(GWC) combines 
three popular 
Win- 
chester 
controllers 
onto one MULTIBUS board: the iSBC 215A open loop controller, 
the iSBC 215B closed 
loop controller, 
and an ANSI X3T9/1226 standard 
interface 
controller. 
The combined 
functionality 
of the 
NEW iSBC 215 Generic Controller 
supports 
up to four 5114", 8" or 14" Winchester 
drives from over 10 differ- 
ent drive 
vendors. 
Integrated 
back-up 
is available 
via two 
iSBX MULTIMODULE 
boards; 
the 
iSBX 218 
module 
for floppy 
disk drives and the iSBX 217 module 
for 114"tape units. ' 


From the MULTIBUS side, the iSBC 215 GWC appears as one standard 
software 
interface, 
regardless 
of the 
drive type used. In short, the iSBC 215 GWC allows 
its user to change drive types without 
rewriting 
soft- 
ware. The iSBC 21'5 Generic 
Controller 
is totally 
downward 
compatible 
with 
its predecessors, 
the iSBC 
215A and 215B controller; 
allowing 
existing 
iSBC 215A and 215B users to move quickly 
to the more power- 
ful iSBC 215 Generic 
Winchester 
Controller. 
In addition, 
the new iSBC 215 GWC directly 
addresses 
up to 
16 megabytes 
of system 
memory. 


The iSBC 215 controller 
is used in all of Intel's 
system 
products, 
including 
the popular 
SYSTEM 86/330. In 
addition 
to its extreme 
flexibility, 
the iSBC 215 controller 
design 
has withstood 
well over 15,000 hours of 


intense 
system 
level testing. 


The 
following 
are trademarks 
at Intel 
Corporation 
and may be used 
only 
to describe 
Intel 
products: 
Intel, 
ICE, iMMX. 
iRMX. 
iSBC. 
iSBX, 
iSXM, 
MULTIBUS. 
MULTICHANNEL, 


MULTIMODULE 
and iCS. Intel Corpor~tion 
assumes 
no responsibility 
for the use of any circuitry 
other 
than circuitry 
embodied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are implied 
.• 
XENIX 
is a trademark 
of Microsoft 
Corporation. 
t iSBC" 
217 1A" tape 
module 
available 
late Q4 '82 


© lNTElCOAPORATION, 
1982 
July, 1982 
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Disk Interface 


The iSBC 215 Generic Winchester 
Controller 
can 


interface 
to over 
10 different 
disk 
drives. 
To 
change drive types the user need only reconfigure 
a minimal 
number of board jumpers 
and, if reo 
quired, insert the proper formatting 
information in· 
to the command parameter blocks. 


The ANSI X3T9/1226 standard interface is a simple 
one·for-one 
flat cable connection 
from drive to 
controller. 


The iSBC 215 controller contains enough on·board 
RAM for buffering 
one full data sector. The con· 


troller is designed to make use of this buffer in all 
transfers. 
The on·board 
sector 
buffer 
prevents 
data overrun 
errors 
and allows 
the 
iSBC 215 
Generic 
Winchester 
Controller 
to occupy 
any 
priority slot on the MULTIBUS. 


High data integrity 
is provided by on·board Error 
Checking Code (ECG) logic. When writing 
sector 
ID or data fields, a 32·bit fire code, for burst error 
correction, 
is appended to the field by the con· 
troller. During a read operation, the same logic reo 
generates the ECC polynomial and compares this 
second polynomial to the appended ECC.The ECC 
logic can detect an erroneous data burst up to 32 
bits in length and using an 8089 algorithm can cor· 
rect an erroneous burst up to 11 bits in length. 


Two iSBX bus connectors 
provide 
110 expansion 


capability forthe iSBC 215 GWC. With the optional 
addition 
of the iSBX 218 Flexible Disk Controller 


MULTIMODULETMand or the iSBX 217 1/4" Tape In· 
terface Module, the iSBC 215 GWC can be con· 
figured into one of four types of peripheral sub· 
systems, see Table 1. 


iSB~ 
iSBXTM 
ISBXTM 


215 
218 
217' 


Winchester Only 
~ 
Winchester+ 
Floppy 
~ 
~ 


Winchester + '14 "Tape 
~ 
~ 


Winchester+ 
Floppy 
~ 
~ 
~ 
+ '!4 "Tape 


Expanded 110Capability 


The iSBC 215 controller 
allows the execution 
of 


user-written 8089 programs located in on·board or 
MULTIBUS system RAM. Thus the full capability of 
the 8089 I/O processor can be utilized for custom 


110 requirements. 


The iSBC 215 Generic Controller interfaces to the 
system CPU(s) through 
MULTIBUS memory. The 


iSBC 215 controller 
directly 
addresses 16 mega- 
bytes of system memory. Commands are passed 
to and from the iSBC 215 via memory based param- 
eter blocks; these parameter blocks are executed 


directly by the iSBC 215 GWC thus off-loading the 
system 
CPU(s). Data transfers 
to and from the 
iSBC 215 GWC are done via the high speed DMA 
capability of the Intel 8089 110 processor. 


NOTE: 
1. Shugart SAIZee or RMS Data Express." 
"Data 
Express is a trademark of Rotating Memory Systems. 


inter 


--------- ~~~~~~~~~~ 


I 
ISBX'~BUS 
I 


CONNECTOR 
I 
I 


Compatibility 


CPU - 
Any iSBC 
MULTIBUS 
computer 
or system 
mainframe. 


Disk Drives - 
Winchester 
Disk Drives; 
both open- 


loop 
and 
closed-loop 
head 
positioner 
types. 
The 


following 
drives 
are known 
to be compatible: 


Open· Loop 


Shugart SA 1000 Series 
Shugart SA 4000 Series 
Memorex 100 Series 
Quantum Q2000 Series 
Fujitsu 2301, 2302 
CDC 9410 
RMS 5'14" Series 
Rodine 5'14" Series 
Ampex 5'14" Series 


Closed· 
Loop 


Priam 8" and 14" Drive Series 


ANSI 


3M 8430 Series 
Kennedy 6170 Series 
Micropolis 
8" Series 


Pertec Trackstar Series 
Priam 8" Series 
Megavault (SLI) 8" Series 


iSBX™ 
MULTIMODULE™ 
Boards 


iSBXTM218 Flexible Disk Controller 
iSBX™ 217 '14" Tape Interface 


Equipment Supplied 


iSBC Generic 
Winchester 
Controller 
Reference 
Schematic 


Controller-to-drive 
cabling 
and connectors 
are not 


supplied 
with 
the controller. 
Cables 
can be fabri- 


cated 
with 
flat 
cable 
and 
commercially-available 


connectors 
as described 
in the iSBC 215 Hardware 


Reference 
Manual. 


Physical Characteristics 


Width 
- 
6.75 in. (17.15 cm) 


Height 
- 
0.5 in. (1.27 cm) 


Length 
- 
12.0 in. (30.48 cm) 


Shipping 
Weight 
- 
19 oz. (54 kg) 


Mounting 
- 
Occupies 
one 
slot 
of 
iSBC 
system 


chassis 
or eardeage/baekplane 


With 
an iSBX MULTIMODULE 
board 
mounted, 
ver- 


tical 
height 
increases 
to 1.13 in. (2.87 em). 


Electrical Characteristics 


Power Requirements 
+ 5 VDC 
@ 3.35A 
max 
+ 5 VDC 
@ 0.15A max' 


+ 12 VDC 
@ 0.15A max' 


- 12 VDC 
@ 0.03A 
max' 


Notes: 
1. On·board regulator 
and jumper allows + 12 voe usage from 


MULTIBUS. 


2. Required 
for some iSBX MULTIMOOULE 
boards. 


Bytes/Sector 
128 
256 
512 
1024 


Priam 8" 
72 
42 
23 
12 
Priam 14" 
107 
63 
35 
18 
RMS/Shugart 8"/Quantum/Ampes/Rodine 
54 
31 
17 
9 
Fujitsu/Memorex 
64 
38 
21 
11 
Shugart 14" 
96 
57 
31 
16 
COC Fineh 
64 
41 
23 
12 
3M (ANSI) 
82 
51 
29 
. 
16 
Megavault (ANSI) 
73 
43 
21 
12 
Kennedy (ANSI) 
74 
43 
·23 
12 
Mieropolis 
(ANSI) 
71 
44 
25 
13 
Pertee (ANSI) 
85 
52 
29 
15 


NOTES: 
1. Maximum allowable for corresponding 
selection of bytes per sector. 


Drives per Controller 


5%" 
Winchester 
Disk 
Drives 
- 
Up to four 
RMS 


Rodine 
or Ampex 
drives. 


8" 
Winchester 
Disk 
Drives 
- 
Up to four 
ANSI, 
Shugart, 
Quantum 
or 
Priam 
drives; 
up 
to 
two 


Memorex, 
CDC, or Fujitsu 
drives. 


14" 
Winchester 
Disk 
Drives 
- 
Up to four 
Priam 


drivers; 
up to two 
Shugart 
drives. 


Flexible 
Disk 
Drives 
- 
Up to four 
drives 
through 


the optional 
iSBX 218 Flexible 
Disk Controller 
con- 
nected 
to the iSBC 215 board's 
iSBX connector. 


%" 
Tape 
Drives 
- 
Up to four 
drives 
through 
the 


optional 
iSBX 217 %" 
Tape Interface 
Module 
con- 


nected 
to the iSBC 215 board's 
iSBX connector. 


Environmental Characteristics 


Temperature 
- 
0° to 55°C 
(operating); 
- 55°C 
to 


+ 85°C 
(non-operating) 


Humidity 
- 
Up to 90% 
relative 
humidity 
without 


condensation 
(operating); 
all 
conditions 
without 


condensation 
or frost 
(non-operating) 


Reference Manual 


144780-001 
- 
iSBC 215 Generic 
Winchester 
Con- 


troller 
Hardware 
Reference 
Manual (NOT SUPPLIED) 


Reference 
manuals 
may be ordered 
from 
any Intel 


sales 
representative, 
distributor 
office, 
or 
from 


Intel 
Literature 
Department, 
3065 Bowers 
Avenue, 


Santa 
Clara, 
CA 95051 


Part Number 
Description 


SBC 215G 
Generic 
Winchester 
Controller 


intel~ 


iSBC 208 


FLEXIBLE DISK CONTROLLER 


• Compatible with all iSBC 80, iSBC 86, 


and iSBC 88 Single Board Computers 


• Controls most single and double 


density diskette drives 


• On·board iSBX bus for additional 


functions 


• Phase lock loop data separator assures 


maximum data integrity 


• Read and write on single or multiple 


sectors 


• User-programmable 
drive parameters 


allow wide choice of drives 
• Capable of addressing 16M bytes of 


system memory 


The Intel iSBC 208 Flexible 
Disk Controller 
is a diskette 
controller 
capable of supporting 
virtually 
any soft- 


sectored, 
double 
density 
or single 
density 
diskette 
drive. The standard 
controller 
can control 
up to four 


drives with up to eight surfaces. 
In addition 
to the standard 
IBM 3740 formats 
and IBM System 34 formats, 


the controller 
supports 
sector 
lengths 
of up to 8192 bytes. The iSBC 208 board's 
wide 
range of drive 


compatibility 
is achieved 
without 
compromising 
performance. 
The operating 
characteristics 
are specified 


under user program 
control. 
The controller 
can read, write, 
verify, 
and search 
either 
single 
or multiple 


sectors. 
Additional 
capability 
such as parallel 
or serial 
110 or special 
math functions 
can be placed on the 


iSBC 208 board by utilizing 
the iSBX bus connection. 


Intel's 8272 Floppy Disk Controller (FDC) circuit is 
the heart of the iSBC 208 Controller. 
On-board 
data separation 
logic 
performs 
standard 
MFM 
(double density) and FM (single density) encoding 
and decoding, 
eliminating 
the need for external 
separation 
circuitry 
at the drive. Data transfers 
between the controller 
and memory are managed 
by a DMA device which completely controls trans- 
fers over the MULTIBUS system bus. A block dia- 
gram of the 
iSBC 208 Controller 
is shown 
in 
Figure 1. 


8218 
BUS 
CONTROLLER 


Universal Drives and the iSBC 208 
Controller 


Because the iSBC 208 Controller 
has universal 
drive compatibility, 
it can be used to control virtu- 
ally any standard- or mini-sized diskette drive. More- 
over, the iSBC 208 Controller 
fully supports 
the 
iSBX bus and can be used with any iSBX module 
compatible 
with this bus. Because the iSBC 208 
Controller is programmable, its performance is not 
compromised 
by its universal drive compatibility. 
The track-to-track 
access, 
head-load, anc;l head- 
unload characteristics 
of the selected drive model 
are program specified. 
Data may be organized in 
sectors up to 8192 bytes in length. 


Figure 1. iSBC 208 Flexible Disk Controller 
Block Diagram 


7-26 


The 
standard 
iSBC 
208 
Controller 
includes 
an 


Intel 
8272 Floppy 
Disk Controller 
chip 
which 
sup· 


ports 
up to four drives, 
single 
or double 
sided. 


SIMPLIFIED 
INTERFACE-The 
cables 
between 


the iSBC 208 Controller 
and the drivels) 
may be low 


cost, 
flat ribbon 
cable 
with 
mass 
termination 
con· 
nectors. 
The mechanical 
interface 
to the board 
is 


a right-angle 
header 
with 
locking 
tabs 
for security 


of connection. 


PROGRAMMING 
- 
The powerful 
8272 FDC circuit 


is capable 
of executing 
high-level 
commands 
that 
simplify 
system 
software 
development. 
The device 


can 
read and 
write 
both 
single 
and 
multiple 
sec- 


tors. 
CRC characters 
are generated 
and checked 


automatically. 
Recording 
density 
is 
selected 
at 
each Read and Write 
to support 
the industry 
stand- 


ard technique 
of recording 
basic 
media 
informa- 
tion on Track 0 of Side 0 in single 
density, 
and then 


switching 
to 
double 
density 
(if 
necessary) 
for 
operations 
on other 
tracks. 


Program 
Initiation-All 
diskette 
operations 
are 


initiated 
by standard 
input/output 
(I/O) port opera- 
tions 
through 
an 
iSBC 
single 
board 
computer. 


System 
software 
first 
initializes 
the 
controller 


with 
the operating 
characteristics 
of the selected 


drive. 
The 
diskette 
is then 
formatted 
under 
pro- 


gram 
control. 
For subsequent 
transfers, 
the start- 


ing memory 
address 
and transfer 
mode 
are speci- 


fied 
for the 
DMA 
controller. 
Data transfers 
occur 
in response 
to commands 
output 
by the CPU. 


Data Transfer-Once 
a diskette 
transfer 
operation 


has 
been 
initiated, 
the 
controller 
acts 
as a bus 


master 
and transfers 
data 
over the 
MULTI BUS at 


high 
speed. 
No CPU intervention 
is required 
until 


the transfer 
is complete 
as indicated 
either 
by the 


generation 
of an interrupt 
on the bus or by exam- 


ination 
of a "done" 
bit by the CPU. 


iSBX BUS SUPPORT 
- 
One connector 
is available 


on the 
iSBC 
208 board 
which 
supports 
the 
iSBX 


system 
bus. This 
connector 
supports 
single-byte 


transfer 
as well 
as higher-speed 
transfers 
super· 


vised 
by the 
DMA 
controller. 
Transfers 
may take 


place 
in polled 
or interrupt 
modes, 
user-selected. 


The presence 
of the iSBX bus allows 
many 
differ· 


ent functions 
to be added 
to the board. 
Serial 
I/O, 


parallel 
I/O 
and 
various 
special-purpose 
math 


functions 
are only 
a few 
of the 
capabilities 
avail- 


able on iSBX MULTI MODULE 
boards. 


Compatibility 


CPU-Any 
iSBC 
MUL T1BUS computer 
or system 


main frame 
Devices-Double 
or single 
density 
standard 
(8") 


and mini 
(51/4") flexible 
disk 
drives. 
The drives 


may be single 
or double 
sided. 
Drives 
known 


to be compatible 
are: 


Standard 
(8") 
Mini 
(51/4") 


Caldisk 
143M 
Shugart 
450 SA 400 


Remex 
RFD 4000 
Mieropolis 
1015-IV 


Memorex 
550 
Pertee 
250 


MFE 
700 
Siemens 
200-5 
Siemens 
FDD 200-8 
Tandon 
TM-100 


Shugart 
SA 850/800 
CDC 
9409 
Pertee 
FD 650 
MPI 
51/52/91/92 
CDC 
9406-3 


Diskette-Unformatted 
IBM 
Diskette 
1 (or equiv- 
alent 
single·sided 
media); 
un formatted 
IBM 


Diskette 
2D (or equivalent 
double-sided). 


Equipment Supplied 


iSBC 208 Controller 
Reference 
Schematic 
Controller· 
to-drive 
cabling 
and connectors 
are not 


supplied 
with 
the 
controller. 
Cables 
can 
be fab- 
ricated 
with 
flat cable 
and commercially-available 


connectors 
as described 
in the 
iSBC 
208 
Hard· 


ware Reference 
Manual 


Physical Characteristics 


Width-6.75 
inches 
(17.15 cm) 


Height-0.5 
inches 
(1.27 cm) 


Length-12.0 
inches 
(30.48 cm) 


Shipping 
Weight-1.75 
pounds 
(0.80 Kg) 


Mounting-Occupies 
one 
slot 
of 
iSBC 
system 


chassis 
or iSBC 604/614 
Cardcage/Backplane. 


With 
an iSBX MULTIMODULE 
board 
mounted, 


vertical 
height 
increases 
to 
1.13 inches 
(2.87 


cm). 


Electrical Characteristics 


Power 
Requirements- 
+ 5 VDC 
@ 3.0A 


Double 
Density 
Single 
Density 


IBM System 34 
Non·IBM 
IBM System 
3740 
Non-IBM 


Bytes per Sector 
256 
512 
1024 
2048 
4096 
8192 
128 
256 
512 
1024 
2048 
4096 


Sectors per Track 
26 
15 
8 
4 
2 
1 
26 
15 
8 
4 
2 
1 


Tracks per Diskette 
77 
256 
77 
256 


Bytes per Diskette 
512,512 
256,256 
(Formatted, per 
(256 bytes/sector) 
(128 byte/sector) 
diskette 
surface) 
591,360 
630,784 
295,680 
315,392 
(512 bytes/sector) 
(256 bytes/sector) 
630,784 
315,392 
(1024 bytes/sector) 
(512 bytes/sector) 


Drive Characteristics 
Standard 
Size 
Mini Size 


Double/Single 
Density 
Double/Single 
Density 


Transfer Rate (K bytes/sec) 
62.5/31.25 
31.25/15.63 


Disk Speed (RPM) 
360 
300 


Step Rate Time 
1 to 16 msec/track 
in 
2 to 32 msec/track 
in 
(Programmable) 
1 msec increments 
2 msec increments 


Head Load Time 
2 t0254 msec in 
4 t0508msec 
in 
(programmable) 
2 msec increments 
4 msec increments 


Head Unload Time 
16t0240msecin 
32 to 480 msec in 
(Programmable) 
16msec increments 
32 msec increments 


Reference Manual 


143078·001-iSBC 
208 
Flexible 
Disk 
Controller 
Hardware 
Reference 
Manual 
(NOT 
SUPPLIED). 
Reference 
manuals 
may be ordered 
from 
any Intel 
sales 
representative, 
distributor 
office, 
or 
from 
Intel 
Literature 
Department, 
3065 Bowers 
Avenue, 
Santa Clara, CA 95051. 


Temperature-O°C 
to 55°C 
(operating); 
- 55°C 
to 
+ 85°C (non-operating) 
Humidity-Up 
to 90% 
Relative 
Humidity 
without 
condensation 
(operating); 
all conditions 
with- 
out condensation 
or frost 
(non-operating) 


Part Number 
SBC208 
Description 
Flexible 
Disk Controller 


iSBC 204 
SINGLE DENSITY FLEXIBLE DISKETTE CONTROLLER 


• Full compatibility 
with iSBC 80, iSBC 
86, and iSBC 88 Single Board 
Computers 


• Direct compatibility 
with most single- 
density, soft-sectored standard- (8") 
and mini-size (5Y4 ") flexible diskette 
drives 


• Software supported by iRMX 80, 
iRMX 86 and iRMX 88 Real-Time Multi- 
tasking Executive disk file system 


• Support 
by CP/M operating 
system 


• DMA input/output allows single board 
computers to process in parallel with 
diskette transfer operations 


• Programmable track-to-track access, 


head-settling, and head· load times 


• Read, write, verify, and search on single 
or multiple sectors 


• Single + 5V supply 


The Intel iSBC 204 Single Density Flexible Diskette Controller is a single board universal diskette controller capable of 
supporting virtually any software-sectored, single density diskette drive. The standard iSBC 204 Controller can control 
two drive surfaces (two single-sided drives or one double-sided drive). With the addition of a second (optional) Intel 
8271 component, up to four drives can be supported. In addition to the standard IBM 3740 formats, the controller sup- 
ports sector lengths of up to 4096 bytes plus mini-size drive formats. The iSSC 204's wide range of drive compatibility 
is achieved without compromising 
performance. The operating characteristics 
(track-to-track access, head-load, and 


head-settling times) are specified under user program control. The controller can read, write, verify, and search either 
single or multiple sectors. 


Intel's 8271 Floppy Disk Controller (FDC) circuit is the 
heart of the iSBC 204 Controller. On-board data separa- 
tion 
logic 
performs 
standard 
FM 
encoding 
and 
decoding, obviating external separation circuitry at the 
drive. Diskette data transfers are DMA (direct memory 
access) through an on-board Intel 8257 DMA controller 
circuit which manages DMA transfers and signals the 
master iSBC processor on completion of the transfer. A 
block diagram of the iSBC 204 Controller is shown in 
Figure 1. 


Universal 
Drive and MUL TIBUS Compatibility 


Because the iSBC 204 Controller 
has universal drive 
compatibility. 
it can be used to control virtually any 
standard- or mini-sized single density diskette 
drive. 
Moreover, the iSBC 204 Controller fully supports the 
microcomputer 
industry 
standard MULTIBUS system 
bus and can be used with any single board computer or 
system compatible with Intel's bus. Because the iSBC 
204 Controller is programmable, its performance is not 
compromised by its universal drive compatibility. 
The 
track-to-track 
access, 
head-load, 
and 
head-settling 
characteristics of the selected drive model are program 
specified. Data may be organized in a fully compatible 
IBM 3740 sector format, in sectors up to 4096 bytes in 
length. or in formats compatible 
with the mini-sized 
diskette drives. 


Interface 
Characteristics 


Expandability 
- 
Each standard iSBC 204 Controller in- 
cludes a single 8271 FDC circuit capable of supporting 
two drive surfaces. Optionally the iSBC 204 may be ex- 
panded to support four single-sided (or two double- 
sided) drives with the insertion of a second 8271 compo- 
nent into an on-board socket. 


Simplified 
Interface 
- The cables between the iSBC 204 
Controller and the drivels) may be either low cost, flat 
ribbon 
cable 
with 
mass termination 
connectors 
or 
twisted pair conductors with individually wired connect- 
tors. An on-board, cross-connect matrix allows optional 
drive control and status signals to be connected while 
maintaining pin-to-pin compatibility. 


Programming 


The powerful 8271 FDC circuit is capable of executing 
high-level commands 
that 
simplify 
system 
software 
development. The device can read, write, and verify both 
single and multiple sectors. CRC characters are gener- 
ated and checked automatically. 
Up to two tracks on 
each surface may be designated "bad" 
and logically 
removed from the diskette. 


Sector 
Scanning 
- 
Scan commands permit sectors to 
be searched for a specified data pattern or "key". During 
scan operations the pattern image from memory is con- 
tinuously compared with a sector or multiple sectors 


read from 
the diskette. 
No CPU intervention 
is required 
until 
a match 
is found 
or all specified 
sectors 
have been 


searched. 


Program 
Initiation 
- 
All 
diskette 
operations 
are 
in- 
itiated 
by 
standard 
input/output 
(1/0) 
port 
operations 
through 
an iSBC 
single 
board 
computer. 
System 
soft- 


ware 
first 
initializes 
the 
controller 
with 
the 
operating 


characteristics 
of 
the 
selected 
drive_ The 
diskette 
is 
then 
formatted 
under 
program 
control. 
For subsequent 
transfers, 
the 
starting 
memory 
address 
and 
transfer 


mode 
are 
specified 
for 
the 
DMA 
controller. 
Data 


transfers 
occur 
in response 
to commands 
output 
by the 


CPU. 


Data Transfer 
- 
Once a diskette 
transfer 
operation 
has 


been initiated, 
the controller 
acts 
as a bus master 
and 


transfers 
data 
over 
the 
MUL TIBUS 
at 
high 
speed. 
No 


CPU intervention 
is required 
until 
the transfer 
is com- 


plete 
as indicated 
either 
by the generation 
of an inter- 


rupt on the bus or by examination 
of a "done" 
bit by the 


CPU. 


CPU - 
Any iSBC MUL T1BUS computer 
or system 
main- 
frame. 


Drive 
- 
Single 
density, 
standard- 
(8") and 
mini-sized 


(51/4 
") diskette 
drives. 
The standard 
iSBC 204 Controller 
supports 
two 
single-sided 
drives 
or one double-sided 
drive. 
By adding 
an (optional) 
8271 
FDC, 
four 
single- 
sided or two double-sided 
drives 
may be supported. 
The 
following 
drives 
are known 
to .be compatible: 


Standard 
Size 
Mini Size 


CDC 9404 
PERTEC 
FD200 


GSl110 
SHUGART 
SA400 


MEMO REX 550 
WANGCO 
82 
MEMOREX 
552 (dual·sided) 


SHUGART 
800 


SHUGART 
850 (dual·sided) 


WANGCO 
76S 


PERTEC 650 (SDIDD. 
DBL. Head) 


Diskette 
- 
Un formatted 
IBM Diskette 
1 (or equivalent 


. single-sided); 
un formatted 
IBM Diskette 
2 (or equivalent 


double-sided); 
un formatted 
Shugart 
SA 104 Diskette 
(or 


equivalent 
mini). 


Data Organization 
and Capacity 


(Standard 
Size Drives) 


IBM Format 
Non-IBM Formal 


Bytes 
per sector 
128 I 256 I 512 
1024 I 
2048 I 
4096 


Seclors 
per track 
26 I 
15 I 
8 
4 I 
2 I 
1 


Tracks per dIskette 
77 
Up to 255 


Bytes per diskette 
256,256 
315,392 


(77 tracks) 
(128·byte 
sector) 


295,680 


(256·byte 
sector) 


315,392 
(S12-byle sector) 


Standard Size 
Mini Size 


Transfer 
rate (KB/secl 
250 
125 


Disk speed 
(RPM) 
360 
300 


Track-la-track 
access 
1 to 255 ms 
2 to 510 ms 


(programmable) 
in 1 ms steps 
in 2 ms steps 


Head settling 
time 
o to 255 ms 
o to 510 ma 


(programmable) 
in 1 ms steps 
if! 2 ms steps 


Head load time 
o to 60 ms 
o to 120 rns 


(programmable) 
in 4 ms steps 
in 8 ms steps 


Equipment Supplied 


iSBC 204 Controller 


Reference 
Schematic 


Controller-to-drive 
cabling 
and connectors 
are not sup- 


plied 
with 
the 
iSBC 
204 
Controller. 
Cables 
can 
be 


fabricated 
easily 
using 
either 
flat 
ribbon 
cable 
or 


twisted 
pair 
conductors 
with 
commercially 
available 


connectors 
as 
described 
in 
the 
iSBC 
204 
Hardware 


Reference 
Manual, 


Optional Equipment 


8271 Flexible 
Diskette 
Controller 
Component 
- 
Adding 


a second 
8271 device 
to the fully 
tested 
circuit 
on the 


iSBC 204 Controller 
allows 
four drive surfaces 
to be sup- 


ported. 


Physical Characteristics 


Width 
- 
6.75 in. (17.15 em) 
Height 
- 
0.5 in. (1,27 cm) 


. Length 
- 
12.0 in. (30.48 cm) 
Shipping 
Weight 
- 
1.75 Ib (0.80 kg) 


Mounting 
- 
Occupies 
one slot of iSBC system 
chassis 


or iSBC 604/614 cardcage. 


Electrical 
Characteristics 


Power 
Requirements 
- 
5.0V (± 5%), 2.5A max 


Environmental 
Characteristics 


Temperature 
- 
o·e to 
55·C 
(operating); 
- 55·C 
to 


+ 85·C 
(nDn-operating) 


Humidity 
- 
Up to 90% 
relative 
humidity 
without 
con- 


densation 
(operating); 
all conditions 
without 
condensa- 


tiDn Dr frost 
(non-operating) 


Reference Manuals 


9800568 
- 
iSBC 204 Diskette 
Controller 
Hardware 
Ref- 


erence 
Manual 
(NOT SUPPLIED). 


9800522 
- 
RMX/80 User's 
Guide 
(NOT SUPPLIED). 


Reference 
manuals 
are shipped 
with 
each product 
only 


if designated 
SUPPLIED 
(see above). 
Manuals 
may be 


Drdered 
from 
any Intel 
sales 
representative, 
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Literature 
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3065 Bowers 


Avenue, 
Santa Clara, California 
95051. 
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Advances in microelectronics and telecommunications 
are changing the way in which information is moved and 
managed. Certainly, computer graphics will be called 
upon to represent much of the technical and business in- 
formation in the coming years. Through Intel's high per- 
formance single board computers and low cost memory 
technology, highly effective implementations 
of com- 
puter graphics display systems are achievable today. 


Computer graphics is one of the many areas of applica- 
tions which once was considered the domain of the 
minicomputer and now may be handled by Intel@micro- 
computers. 


The purpose of this note is to acquaint you with some of 
the hardware 
and software techniques which are re- 
quired to form useful display systems with high per- 
formance microcomputers 
and raster graphics display 
devices. The system discussed in this note will generate 
displays of area filled polygons as well as simple line 
drawings, both of which are typical of business and engi- 
neering information 
encountered in the office, labora- 


tory, and factory environments. 


This application note will lead the reader through a com- 
plete implementation example of the hardware and soft- 
ware of a display system which will produce either a 
256 x 240 pixel color display or a 512x 480 pixel mono- 
chromatic (black and white) display. First, the note dis- 
cusses raster scan display devices and the demands that 
their parameters place on a microcomputer-based 
con- 


troller. Then, a MULTIBUS@-based frame buffer (bit 
mapped) prototype display controller is described. After 
considering the programmer's view of this hardware, the 
graphics support software is outlined from its PL/M-86 
implementation. 


Though the frame buffer board described in this note is 
not an off-the-shelf Intel@product, the straightforward 
implementation demonstrates how easily a display sys- 
tem capability can be added to the MULTIBUS@system 
bus for applications which require graphics. 


Throughout this note are numerous references to the ex- 
cellent text on computer 
graphics 
by Newman and 


Sproull'. If you are new to the field of computer graphics 
it is recommended that you read the chapters on raster 
graphics. 


Of the various alternatives for graphics display devices 
(direct view storage tube, calligraphic display, plasma 
panels, etc.) the raster scan cathode ray tube (CRT) 


display is a dominant 
technology. 
The display elec- 
tronics has the advantage of volume production 
eco- 


nomics, driven by the consumer television industry, and 
the display controller enjoys price reductions offered by 
the random access memory (RAM) experience of the 
semiconductor industry. 


Many CRT computer terminal displays already offer a 
limited graphics capability by allowing the user to select, 
and in some cases, even reprogram, 
a set of graphics 


characters 
which can be used to compose a limited 


amount of graphic scenes. Intel@will soon offer the 
iSBX 270 MULTIMODULE Video Display Controller 
which can be added to any Intel@Single Board Com- 
puter with iSBX MULTIMODULE 
board capability. 


The iSBX 270 board is based on the Intel@8275 and is 
primarily a character display controller although limited 
graphics capabilities are available by changing the char- 
acter generator of the board. Such displays can be quite 
effective for a particular application and because of LSI 
display controller components like the Intel@8275 and 
8276 the cost of these display systems is quite low. 


This application note is directed exclusively at a display 
system with full graphics capability. Such raster scan 
graphic display systems are referred to as BIT-MAPPED 
DISPLAYS, 
where each PIXEL (picture element) of 


video information 
is mapped 
into unique 
bit(s) of 


memory, or as FRAME BUFFER DISPLAYS, because 
digital memory is used to store a copy of a frame of 
video information. 


To understand 
how computer-generated 
images are 


formed it is useful to first understand how a home tele- 
vision receiver produces a picture. The display hardware 
in a television receiver is approximately the same as that 
used in computer-based raster display systems. 


Broadcast television represents each portion of a picture 
as a FRAME of information. The television frame is the 
electronic analogy to a frame of movie film. Unlike the 
analog image on a film frame, a television frame is com- 
posed of a discrete number of SCAN LINES. To pro- 
duce a picture, the CRT's deflection circuits force an 
electron beam to scan across the face of the CRT from 
left to right, modulating the beam's intensity in propor- 
tion to the brightness of the corresponding line of the 
picture. The beam excites the inside surface of the phos- 
phorous-coated CRT face and produces light. This scan- 
ning operation is repeated in sequence from the top of 
the screen to the bottom for each of the scan lines which 
comprise the image. As the electron beam arrives at the 
right of the screen at the completion of each scan line, 
the beam is first BLANKED and then DRIVEN to 
RETRACE 
a path back to the left of the screen in 


preparation 
for the next scan line. The blanking is per- 
formed so that no extraneous image forms as the beam 
passes from right to left. Similar to the HORIZONTAL 
SYNCHRONIZATION 
process just described is that 
for the vertical axis of the display. To force the beam to 
start forming the picture with the upper leftmost corner 
of the screen, a VERTICAL 
SYNCHRONIZATION 
signal causes the beam to be swept from the bottom of 
the CRT to the top. During this interval the beam also 
must be blanked to avoid corruption 
of the picture. 
Thus, there are five major signals which control the 
display process in a CRT display: 


Horizontal Synchronization (or Horizontal Drive) 
Horizontal Blanking 
Vertical Synchronization (or Vertical Drive) 
Vertical Blanking 
Blanked Video Intensity 


Most raster scan monitors derive their basic specifica- 
tions from broadcast television standards. Serious video 
enthusiasts 
should 
review the Electronic 
Industries 
Association 
standards 
in this area. 
Three such in- 
teresting documents are listed in the Bibliography2.J, •• 
These standards specify the analog voltage combination 
of video picture information and synchronization con- 
trol signals which must be produced. 
This composite 
video signal is electricaIly complex because it must be 
broadcast over a single television channel and be band- 
width limited to a few megahertz. CRT data monitors 
often abandon the composite video approach and aIlow 
the individual constituents of the signal to be applied 
separately as blanked video data, horizontal synchroni- 
zation (drive), and vertical synchronization 
(drive). 
Also, in the separated video approach, TTL signal levels 
are allowed at the monitor interface to simplify the con- 
troIler design. 


Raster scan display monitors may be purchased with a 
variety of interface configurations. 
One type of inter- 
face which is widely used is known as COMPOSITE 
VIDEO. Composite video is so named because informa- 
tion is supplied to the monitor on a single coaxial cable 
which carries an analog combination 
of the video, 
blanking, and synchronization signals described earlier. 
In a color system, this composite signal becomes com- 
plex to produce since it consists of a vector combination 
of the red, green, and blue video data and the syn- 
chronization 
information. 
This composite 
signal is 
decomposed 
by the monitor 
into 
the constituent 
elements which are required to form an image. 


Another type of interface is the separate sync variety. 
With monitors of this style, the user provides blanked 
video and synchronization 
on separate cables. For a 
color system, the blanked video is usuaIly supplied on 


three separate coaxial cables, carrying red, green, and 
blue video information. These monitors are often called 
RGB monitors, signifying the individual control which 
the separate video cables provide. In a monochrome 
system, the blanked video is supplied on a single cable. 
Furthermore, though many monitors allow proportional 
analog voltage control of beam intensity, TTL signals 
are usually accepted directly and produce fuIly saturated 
beam intensities. 


Regardless of the monitor chosen, a set of specifications 
for synchronization, 
blanking, and video must be met. 


Though monitors vary widely in the precise require- 
ments for these signals there are a few common denomi- 
nators based on commercial television standards. 


In countries with power systems based on 60 hertz 
operation, frames are sequenced to a television set at a 
rate of 30 times per second, implying that a new field is 
encountered 60 times per second. (See the description of 
interlaced 
fields 
in the 
next 
section 
on INTER- 
LACING.) In countries using 50 hertz power, these fre- 
quencies are scaled appropriately. Throughout this note, 
a 60 hertz power system will be assumed. 


The vertical synchronization signal occurs at a rate of 60 
hertz. 
With two interlaced 
vertical fields per video 
frame, the frame rate is 30 hertz. 525 horizontal scan 
lines per frame implies a horizontal synchronization rate 
of 15750hertz [(30 frame/second).(525 
horizontal scan 
lines/frame»). 
A horizontal 
scan line requires 63.49 
microseconds (1/15750 hertz). 


The width 
and positioning 
of the synchronization 
signals (with respect to the blanked video data) must be 
tailored to the particular monitor to best center the in- 
formation on the CRT face. 


Of the 63.49 microsecond period of a horizontal scan 
line, some 10 to 15 microseconds are normally required 
to retrace the electron beam to the left of the CRT in 
preparation 
for the next scan line. During this retrace 
period the video data stream must be blanked. Similarly, 
a vertical retrace period occurs at the start of each new 
field of the interlaced display during which time the 
video data must also be blanked. Typically 450 to 480 of 
the 525 total scan lines of a display are useable for the 
presentation of information, the rest being consumed by 
the vertical retrace periods. 


CRT monitors used for television display a frame of in- 
formation as two INTERLACED FIELDS of scan lines. 
The interlace process simply divides the frame into two 
sets of scan lines. First, one field (set of scan lines) is 
displayed by the raster scan technique. Then, the elec- 


inter 


tron beam is retraced to the top left corner of the CRT, 
offset by one half of the vertical spacing of scan lines, 
and the second field is scanned. Thus half of the picture 
is displayed on one scan and the other half on a subse- 
quent scan. Figure I compares the travel of the electron 
beam on a non-interlaced 
display with that of an in- 


terlaced display. 


CRT data terminals normally utilize only one of these, 
fields when forming the ubiquitous 1920 (24 rows of 80 
columns) character display. There are two reasons for 
this. First, the display controller electronics is somewhat 
easier to construct without the interlace requirement. Per- 
haps more importantly, the problem of display FLICKER 
is avoided by making the frame rate equal to the field 
rate. High resolution graphics displays require the use of 
both fields to achieve maximum resolution. 
In these 


graphics displays, flicker can be an annoying problem. 


The phosphorescent coating applied to the inside surface 
of a CRT exhibits a PERSISTENCE to continue to emit 
photons after a region has been excited by the electron 
beam. Most conventional 
monochrome 
CRT displays 
and television monitors utilize a tube with P4 phosphor 
which decays to 0.1 % 
of its original intensity in 20 


milliseconds. The persistence of the P4 phosphor is long 
enough for the human eye to capture the information in 
a single frame of a television display and yet not so long 
that a sequence of fast changing action leaves artifacts 
or ghosts of the previous frames behind to confuse the 
viewer. Furthermore, 
television scenes produced with 


typical cameras are incapable of representing features 
which occupy a single scan line of the display. Informa- 
tion on one scan line of a camera-generated 
image 


unavoidably carries some of the information of the scan 
line above it and the scan line below it. Remember that 
the adjacent scan lines are in different fields. As these 
camera-generated lines are displayed, the eye blends the 
information together to form an apparently flicker-free 
image. 


When an interlaced 
frame of video information 
is 


digitally-generated, 
adjacent pixels may be (and often 


are) of greatly 
different 
intensities. 
Furthermore, 


because of interlacing, the adjacent pixels on a horizon- 
tal scan line are excited by the electron beam at a rate of 
30 times per second, 
once each 
frame. 
Vertically 


neighboring pixels, produced by members of alternate 
fields of the frame, are illuminated at intervals of 1/60 
of a second. See Figures 2 and 3 which illustrate the dif- 
fering refresh intervals for adjacent pixels on horizontal 
and vertical lines. Notice that for the horizontal row of 
pixels, the beam visits the group once every two fields. 
However, for a vertical column of pixels the beam il- 
luminates one half of the line with field 0 and the other 
half of the line with field I. Half of the vertical column 
of pixels is drawn during each field. This disparity of 
refresh rates causes horizontal 
lines, and lines with 


primarily horizontal segments, to flicker noticeably if 
the monitor employs the conventional P4 phosphor used 
in character displays. 
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One answer to this problem is quite straightforward and 
requires that the monitor be equipped with an optional 
(often at no extra cost) phosphor. EIA P31 or EIA P39 
phosphor produces satisfactory flicker-free displays but 
retains 
standard 
monitor 
interface. 
For the mono- 


chrome display option 
in this application 
note, the 


choice was made to select a long persistence phosphor 
(P39) and preserve the conventional interlaced display 
monitor interface. 


Another approach to eliminate flicker is to abandon in- 
terlacing, 
discard the information 
in one field, and 


thereby make the frame rate equal to the field rate of 60 
per second. Unfortunately, 
this also limits the vertical 


resolution possible with a conventional monitor to one 
half of that which is available. The color display option 
was implemented by using a non-interlaced display for- 
mat for this application. 
Higher performance 
non- 


interlaced 
monochrome 
monitors 
are now available 


which can offer 800 to 1024 horizontal lines of flicker- 
free display with P4 phosphor. The cost of these displays 
is usually two to four times that of a conventional 
monochrome monitor. 


The hardware 
used in this application 
consists of a 


standard 
iSBC 86/12A 
microcomputer 
and a wire- 


wrapped prototype board which implements a frame 
buffer 
for the MULTIBUSI!lsystem bus. These two 


boards provide a hardware framework for generating 
graphic displays on either color or monochrome display 
monitors. Figure 4, Display System Organization, shows 
a block diagram of this system. The iSBC 86/ 12A board 
contains the powerful 8086 processor, 
32K bytes of 


RAM, and 8K bytes of PROM using Intell!l2716 devices. 
This provides sufficient program storage and processing 
power 
to implement 
sophisticated 
graphic 
display 
systems. 


Since the frame buffer refreshes the display from a dual 
ported RAM,-the MULTIBUSI!lsystem bus is only used 
when the microcomputer updates the RAM. Thus, the 
system bus is free for whatever the application 
may 
require. 


Detailed descriptions 
of the frame buffer hardware, 
copies of the schematics, timing diagrams, and PROM 
codes for the two state machines may be found in the 
Appendices (A, B, C, and D respectively). For necessary 
background, the next section provides a brief summary 
of the hardware facilities. 


Components of the Frame Buffer 


A more detailed view of the frame buffer is shown in 
Figure 5, Block Diagram of Frame Buffer. The buffer 
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itself is composed of two RAM arrays named "A" 
and 
"B", each containing 32K bytes of dynamic RAM. This 
RAM may be accessed as 8-bit bytes or 16-bit words. 
Two ports to the RAM are provided, 
the first for 


MULTIBUS"l access and the other for use by the display 
controller section. A two port arbitration logic section 
schedules accesses to the RAM array, guaranteeing that 
the display controller receives timely access and inter- 
leaving MULTIBUS<!laccess when the RAM is unused 
by the display controller. A central timing unit based on 
a 10 megahertz crystal reference controls activity on the 
entire board, including the precise signals needed to con- 
trol the dynamic RAM array. 


Two finite state machines, one for control of horizontal 
synchronization and one for vertical synchronization of 
the display, adapt the general hardware to specific re- 
quirements 
of different 
monitors. 
These two state 


machines are microprogrammed using 2716 PROMs and 
may be reprogrammed 
for added flexibility. The state 


machines control the advance of the video refresh ad- 
dress counters which scan the RAMs in sequence to ob- 
tain all the necessary bytes to form the display. Four 
shift registers capture RAM data and serialize it for the 
video output circuits. The shift registers are appropri- 
ately named RED, GREEN, BLUE, and XTRA. 


Video output. circuits combine the shift register data 
with blanking and synchronization 
information 
from 


the state machines to produce the video signals needed to 
drive a variety of display monitors. 


inter 


The frame buffer may be used to control either a color 
display 
or a monochromatic 
display. 
A hardware 
jumper selects one of the display modes. 


This frame buffer can be employed in color mode or in 
monochrome mode. In color mode, three blanked video 
data outputs are provided (RED, GREEN, and BLUE) 
as well as a synchronization signal. The color mode pro- 
duces a display of 256 x 240 picture elements (PIXELS), 
each of which is three bits of information. 
The XTRA 


shift register data might be used for other functions like 
highlighting or blinking control but it was not utilized in 


this application. The display convention is that the least 
significant bit of a display byte is the first bit to be 
displayed as the electron beam moves from left to right. 
Consecutive higher order bits follow in sequence. The 
RED bytes are the even addressed bytes of the "A" 
RAM. The GREEN bytes are the odd addressed bytes of 
the" A" RAM. The BLUE bytes are the even addressed 
bytes of the "B" 
RAM. The XTRA bytes are the odd 


addressed bytes of the "B" 
RAM. For each pixel of a 


color mode display, three bits of video information are 
required, one from each of the RED, GREEN, 
and 


BLUE shift registers. Thus to program the display it is 
useful to have a map of which memory bits map into 
which screen pixels. Figure 6 shows such a mapping for 
the color mode display. 
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Black/White (Monochromatic) Mode 


To select monochromatic 
operation, 
the COLOR 


jumper must be installed in the Black/White position. 
When this is done the display changes to a 512 x 480 
pixel format where each pixel is represented by a single 
bit from the frame buffer RAM. All the bytes to repre- 
sent a full image are contained in the" A" RAM. With 
the duplication of some output circuits, the "B" RAM 
could produce another image and the board would be 
capable of supplying data to two independent monitors 
simultaneously. 


Figure 7 shows the mapping of bytes of the frame buffer 
into pixel groups on the display. Again the least signifi- 
cant bit of a byte is the first to be displayed with the 
others following in ascending order. 


Appendix E contains a listing for a PLlM-86 program 
which implements a set of primitive graphic routines. 
This program 
may be obtained 
in machine-readable 


form from the Intell!>Insite Program 
Library. These 


routines are useful for forming many kinds of bit- 
mapped images. In this section of the application note, a 
thumbnail 
sketch is provided for the important 
com- 


ponents of the program. 


Throughout 
the discussion, the X,Y coordinates 
(to 


specify points, 
endpoints 
of lines, 
and vertices 
of 


polygons) are implicitly in the appropriate range for the 
type of display, color or monochrome, 
which has been 


selected with the COLORMODE 
switch. When COL- 


ORMODE is set to the Boolean TRUE, the range of X is 
o to 255 and the range of Y is 0 to 239. When COLOR- 
MODE is set to FALSE then the range of X is 0 to 511 
and the range of Y is 0 to 479. As an added protection, 
particularly for the interactive use, run-time checking is 
performed on all X,Y coordinates passed as actual para- 
meters to the graphic primitive routines (see PTERROR 
procedure in the listing, Appendix E, line 213). 


Point Plotting 


The most basic of the primitive graphic operations is the 
modification of a single pixel of the display. Though ap- 
plications programs rarely use this primitive, point plot- 
ting is invoked repeatedly during vector generation. 
Thus while it is implemented here in a high level pro- 
cedure this routine is one of the first to be considered for 
assembly language coding when vector performance is 
of the utmost. The PL/M-86 skeleton of this procedure 
is: 


PLOTPT: PROCEDURE (X,Y); 
DECLARE (X,Y) ADDRESS; 
END PLOTPT; 
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The procedure is contained in Appendix E starting at 
line number 226. The X and Y parameters specify the 
pixel address of the frame buffer that is to be modified. 
Appropriate shift and mask operations convert X and Y 
into a word address, PADR, which indexes into the 
frame buffer. 
The least significant 
four bits of the 


X-coordinate specify the bit position within the word to 
be modified. 


A global byte variable PLOTMODE (Appendix E, line 
number 36) controls the operation to be performed on 
the specified pixel. The PLOTMODE 
operations 
are 


coded: 


PLOTMODE 
0: 
Operation 
pixel = pixel OR 1; 
/* Set pixel */ 
pixel = pixel AND 0; 
/* Clear pixel */ 
pixel = pixel XOR 1; 
/* Complement pixel */ 
/* undefined */ 


Line Drawing 


Chapter 2 of Newman and Sproull' is devoted to "Point 
Plotting 
Techniques" 
and the algorithm 
used to 


generate lines in this system is described on page 26. 
Bresenham's algorithm for implementing the digital dif- 
ferential analyzer (DDA) is coded in procedure DDA 
(Appendix E, line number 242). The PL/M-86 skeleton 
~: 
. 


DDA: PROCEDURE (Xl,Yl,X2,Y2); 
DECLARE (Xl,Yl,X2,Y2) 
ADDRESS; 
ENDDDA; 


Xl, Yl and X2,Y2 are the endpoints of the line to be 
drawn by DDA. First the coordinates are sorted so that 
Y2~ Y1; Then the absolute value of the differences in X 
and Y coordinates (see Figure 8, DELX and DELY) are 
recorded in DELX and DEL Y (and twice those values in 
DELX2 and DEL Y2). 


Three special cases are handled. A line whose endpoints 
are identical (Xl = X2 and Yl = Y2) plots as a single 
pixel at Xl, Yl. Horizontal lines (DEL Y= 0) and vertical 
lines (DELX = 0) are handled by simple loops which 
draw those special cases more efficiently. 


If the line is not one of the three special cases described 
above, it is checked to determine whether the DELX or 
DELY component of the slope of the line is greater and 
an appropriate loop is initiated. The variable REM car- 
ries the remainder 
(or "e" 
error as in Newman and 


Sproull) for the incremental 
process which computes 
where each scan line of the display intersects the line seg- 
ment being drawn. REM is a measure of the error gener- 
ated as the points of a line are quantized for the frame 
buffer. 


Much of the power of raster graphic displays comes 
from their ability to display area-filled rectangular and 
polygonal 
areas. 
Though 
calligraphic 
and storage 


display devices can surpass raster displays in vector 
generation speed they lack the ability to fill areas or lend 
tone (and optionally color) to drawn areas. 


The basic operation used to fill solid rectangular and 
polygonal areas is the inking (with a selected pattern, 
and possibly color) of the pixels on each visible scan line 
which comprises the image. The procedure INKLINE 
(Appendix E, line number 319) performs this operation. 
Its PL/M-86 skeleton is: 


INKLINE: PROCEDURE (Xl,X2, YSCAN); 
DECLARE (Xl,X2,YSCAN) 
ADDRESS; 


END INKLINE; 


Xl and X2 are the X coordinate extremes for the line of 
pixels to be drawn on the YSCAN scan line of the 
display. As might be expected, YSCAN has a range of 0 
to 239 in color mode and 0 to 479 in black/white mode. 
First, Xl and X2 are sorted such that Xl~ X2. Then a 
LEFTMASK and RIGHTMASK are formed which are 
used to perform partial word modifications which may 
occur at the left and right edge words of the scan line. 
Here the repeated shift of the 8086 is utilized, a very 
useful operation for many graphic primitive functions. 
XWORD is a count of the number of whole words of 
pixels which need to be modified. If XWORD=O, 
the 


pixels at Xl and X2 are included in the same word of 
frame buffer memory. 


PLOTMODE affects the modification in much the same 
way as it did in PLOTPT, except that in INKLINE the 


modification is word oriented rather than pixel oriented. 
Thus, 


PLOTMODE 
0: 
Operation 
word =word OR Offffh; 
/. Set a word of pixels ./ 
word = word AND OOOOOh; 
/. Clear a word of pixels ./ 
word =word XOR Offffh; 
/. Complement a word of pixels ./ 
/. undefined ./ 


Rectangle Plotting 


Rectangular 
areas of the image are modified by the 
PLlM-86 
procedure 
PLOTRECT 
(Appendix E, line 
number 365) whose skeleton is: 


PLOTRECT: PROCEDURE (XO,YO,XI,YI); 
DECLARE (XO,YO,XI,YI) ADDRESS; 
END PLOTRECT; 


XO,YOand XI,YI are a pair of vertices which describe 
the endpoints of one of the diagonals of the rectangle to 
be filled. It is a straightforward 
process to fill the 
specified rectangle by calling INKLINE repeatedly, once 
for each visible scan line of the rectangle. PLOTRECT 
may be used to fill any rectangle whose edges are or- 
thogonal to the coordinate axes. By clever control of the 
PLOTMODE, 
PLOTRECT can be used to fill, clear, 
and complement rectangular regions of the display. 


Polygon Area Filling 


Solid area filling of polygonal areas is a much more com- 
plicated task than that just explained for rectangles. 
Chapter 
16 of Newman and Sproull' 
entitled "Solid 
Area Scan Conversion" outlines a number of alternative 
methods for area filling polygons. 


A polygon may be represented as an ordered set of ver- 
tices; or as an ordered set of line segment edges. The 
PLlM-86 program in Appendix E records polygons in a 
data structure which is edge-oriented but provides a set 
of procedures 
to access that data structure 
which is 
vertex-oriented. This approach allows a user to traverse 
the vertices of a polygon in a natural fashion when filling 
the data structure. The fundamental polygon data struc- 
ture (Appendix E, line numbers 23 through 35) is repre- 
sented by the following PL/M-86 statements: 


DECLARE EDGELIMIT LITERALLY '32'; 
DECLARE (XO(EDGELIMIT), YO(EDGELIMIT» 
ADDRESS; 
DECLARE (XI(EDGELIMIT),Yl(EDGELIMIT» 
ADDRESS; 


DECLARE (POL YEDGES, THISEDGESET) 
ADDRESS; 


The vertex-oriented procedures are fairly self-explana- 
tory from their PLlM-86 skeletons: 


STARTPOLY:PROCEDURE(X,n; 
/. Appendix E, line number 409 ./ 


DECLARE (X,Y) ADDRESS; 
END STARTPOLY; 


ADDVERTEX: PROCEDURE 
(X,Y); 
/. Appendix E, line number 418·/ 


DECLARE (X,n 
ADDRESS; 
END ADD VERTEX; 


ENDPOLY: PROCEDURE; 
/. Appendix E, line number 439 ./ 


END ENDPOLY; 


NEWEDGESET: PROCEDURE (X,Y); 
/. Appendix E, line number 428 ./ 


DECLARE (X,Y) ADDRESS; 
END NEWEDGESET; 


To demonstrate how these procedures are used and how 
the data structure is filled, consider Figure 9, A Test 
Triangle. The triangle has vertices (2,2), (4,6), and (6,3). 
Alternatively the triangle could be represented 
by a 
polygon with edges whose endpoints are «2,2),(4,6», 
«4,6),(6,3», 
and «6,3),(2,2». 


(4,6) 
••• 


Figure 9. A Test Triangle' 


The PL/M-86 data structure for this polygon is created 
by the following series of calls: 


CALL STARTPOLY(2,2); 
CALL ADDVERTEX(4,6); 
CALL ADDVERTEX(6,3); 
CALL ENDPOLY; 


The ADDRESS 
variables POL YEDGES and THIS- 


EDGESET are pointers into the edge data structure. 
POL YEDGES points to the last valid edge specified. 
Since PL/M-86 
arrays are zero indexed, 
if POLY- 
EDGES = 2 then three edges have been specified. 
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To accommodate a more complicated set of polygonal 
images one can consider a solid area image to be de- 
scribed by several distinct sets of polygon edge data. 
These edge sets might, for instance, describe the outer 
and inner edges of an image such as the "0" shape of 
Figure 10. As the data structure is filled, THISEDGE- 
SET points to the first edge of this (the current) edge set 
of the polygon. For the graphical object in Figure II, 
Unusual Shape, the edge sets of this polygon could be 
specified by the following series of PLlM-86 calls. 


The outermost edge set. 


CALL STARTPOLY(2,2); 
CALL ADDVERTEX(2,12); 
CALL ADDVERTEX(l2,12); 
CALL ADDVERTEX(12,2); 


The triangular inner edge set. 


CALL NEWEDGESET(3,6); 
CALL ADDVERTEX(5,3); 
CALL ADDVERTEX(lI,6); 


The rectangular inner edge set. 


CALL NEWEDGESET(lO,7); 
CALL ADDVERTEX(lO,IO); 
CALL ADDVERTEX(4,1O); 
CALL ADDVERTEX(4,7); 
CALL END POL Y; 


It is not important in which direction the vertices are 
visited when describing 
an edge set. Clockwise 
or 


counterclockwise order is acceptable. Whichever order 
has been selected must then be maintained for all the ver- 
tices on any particular edge set. 


Filling a polygon is then the process of finding, for each 
visible scan line of the polygon, the intersection of all 
edges of the polygon with the scan line. These intercepts 
are sorted and accumulated in pairs of ascending X 
values. The first X-intercept on a scan line causes scan 
line inking to begin and the second X-intercept causes 
scan line inking to stop. This process may be repeated 
for several line segments to form all the visible detail on 
a single scan line. The process is repeated for all the visi- 
ble scan lines of the polygon. Only memory constraints 
limit the size of the polygon edge structure, and hence 
the complexity (number of edges) of polygons which can 
be plotted. 


Figure 12 is a state diagram for the proper sequences of 
calls to the vertex-oriented procedures 
for filling the 


polygon data structure. 
A call to STARTPOLY pro- 


vides the first vertex of the first edge set of the polygon 
being described. Any edge set must contain at least three 
edges since a triangle is the simplest polygon which can 
be represented and displayed. Thus a minimum of two 
additional calls to ADDVERTEX must follow. Notice 
that ADDVERTEX 
can be repeatedly called to con- 
struct arbitrarily complex edge sets. Either END POL Y 
(if this is the last edge set) or NEWEDGESET is invoked 
to terminate an edge set. END POL Y also terminates the 
polygon data structure. NEWEDGESET terminates the 
edgeset just constructed 
and specifies the first coor- 


dinates of a new edge set which is to be started. The sum 
of the number of calls to STARTPOLY, 
ADDVER- 


TEX, and NEWEDGESET must be less than or equal to 
the EDGELIMIT value. 


Figure 
12. State 
Diagram 
for Vertex·Orlented 
Figure 
11. 
Unusual 
Shape 
Procedure 
Calls 
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Indeed, the PL/M-86 program in the Appendix contains 
far more than just the primitive graphics operations 
described above. A simple user interface is provided to 
allow interactive access to a few illustrative operations. 


In Appendix E is a demonstration 
program which il- 
lustrates how an application can be constructed. 
This 
program 
has a set of predefined graphic operations 
which can be invoked to produce some graphic displays. 
It also allows the user to interact with the system and 
dynamically construct 
polygons with a simple input 
device called a turtle. 
. 


At either the 'turtle' or the 'main' level of the program 
typing 'h' will generate a help file of the program options. 


The predefined operations of the program are functions 
which do useful things such as clear the frame buffer, set 
graphic modes, establish the polygon data, plot color 
test patterns, etc. The main level help file lists all the 
functions which may be invoked. 


The demonstration program contains the simplest of all 
graphic input devices, the turtle. By typing a 't' to the 
main command level, the turtle level is entered. In the 
turtle 
section of the program, 
a small rectangle 
is 
displayed which signifies the present location of the tur- 
tle. The turtle is commanded by the user through single 
character directives, 'u' for up, 'd' for down, 'I' for left, 
and 'r' for right; an effective though somewhat tedious, 
process. The crawlspeed, the distance which the turtle 
moves for each of the direction commands, 
may be 
varied. 


Additional single character commands allow the poly- 
gon procedures to be invoked, each one adding a vertex 
to the polygon data structure based on the current loca- 
tion of the turtle on the graphics display. As each point 
is added the edges being added to each edgeset of the 
polygon are displayed on the graphics screen. When the 
exit key, 'e' is typed the polygon data structure is com- 
pleted, the turtle erased, and the main command loop 
entered. The specified polygon may then be plotted. 


Intel's iSBC 86/12A and iSBC 86/05 (8 MHz perform- 
ance) single board computers, based on the 8086 micro- 
processor, 
bring minicomputer 
performance 
to the 
MULTIBUS'" system bus. Supporting an address space 
of I million bytes, these microcomputers allow memory- 
intensive applications which were previously limited by 
less capable processors. 16-bit data transfers also afford 
dramatic performance improvements, 
for applications 
like computer 
graphics, 
over that 
of earlier micro- 
computers. 


Many products can benefit from raster graphic display 
devices. Electronic graphic displays allow information 
to be presented in a more natural manner than can be 
done with simple character-based 
displays. The infor- 
mation bandwidth between a microcomputer system and 
a human user can be greatly increased through graphics. 


Raster graphics displays are an exciting alternative out- 
put medium for microcomputer systems. The combina- 
tion of Intel's powerful 16-bit microcomputers and the 
flexible MULTIBUS'" system bus provides a high per- 
formance hardware host for such products. 
With the 
PL/M-86 language system, development of graphics ap- 
plication software is simplified. This application note 
demonstrates how easy and economical it is to utilize 
this technology. 
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APPENDIX 
A 
MULTIBUS@FRAME BUFFER HARDWARE 
DESCRIPTION 


The hardware for the MULTIBUS® Frame Buffer con- 
sists of several sections of logic: 


Two Port Memory Control Logic 
Address Generation for Video Refresh 
Synchronization and Blanking Logic 
MULTIBUS® Interface Logic 
Video Output Logic 


These will be discussed individually. Please refer to the 
schematics in Appendix B. 


The two port 
memory 
control 
logic manages 
the 


64K byte dynamic RAM array. It provides video re- 
fresh data to the display, read/write 
access by the 


MULTIBUS® master, and synchronous management of 
refresh cycles for the dynamic RAM chips. 


An Intel@8224 Clock Generator and Driver with a 10.0 
MHz crystal provides the timing reference clock (PIXCLK) 
for the display controller. 
A 74S163 counter divides 


down PIXCLK to form 16 states called SF...SO. These 
states are partially 
decoded by a 3205 one-of-eight 
decoder and after additional gating are resynchronized 
with a 74S374 pipeline register to form the seven basic 
control signals on the board. The function of each of 
these signals is described as follows: 


Start generating RAS/ for the memory 
array. 
Start generating the row address enable 
signal (ROWEN). 
Start generating CAS/ for the memory 
array. 
End control signals. 
Latch memory data for return to the 
MUL,TIBUS®system bus. 
Load video shift register data when enabled 
by SRENB. 
Advance address counters and state 
machines. 


NDCTLI 
LATCH 


The two port memory control logic timing diagram in- 
cluded in Appendix C describes the generation of these 


signals. States SOthrough S7 are reserved for the use of 
the video refresh port and for dynamic 
RAM chip 
refresh. States S8 through SF are reserved for possible 
MULTIBUS® access. Thus it is always possible for the 
processor 
to access the memory 
between 
video or 
dymanic RAM refresh cycles. 


The video refresh 
address counter 
consists of four 
74LSI63 binary counters. The 14 bit address which is 
formed selects two 16bit words in the frame buffer RAM, 
one from the "N' RAM and one from the "B" RAM. A 
multiplexing scheme on the address bus AD... AOpresents 
the MULTIBUS@addresses ADRE/ ... ADRI/ when BUS 
is active or the video refresh addresses, Y8 
YO and 
X4.. .x0 when BUS is inactive. Obviously Y8 
YOcor- 
responds to the scan line address and X4 
XO cor- 
responds to the 16 bit word within the scan line. 


A 74S74 flip flop generates the signal ODD (ODD = 0 
for field 0, ODD= I for field I). The X-V address 
counter latches the value of ODD at the beginning of 
each field of the display and YOcarries the latched value 
of ODD for the duration of the field. 


Synchronization and Blanking Logic 


Two finite state machines generate all synchronization 
and blanking signals. In addition these machines control 
the advance of the video refresh address counters and se- 
quence the video shift register data. The signal COLOR 
is an input to each of these machines which changes their 
operation to accomplish the appropriate display format. 


One of these machines is the horizontal state machine 
and it consists of two 74LSl63 counters and an Intel®2716 
PROM. One of the counters serves as the state counter 
and the other as a duration counter for the amount of 
time to remain in the current state. The horizontal con- 
trol PROM examines the current horizontal 
machine 
state (HCP3 ... HPCO), the condition of the vertical state 
machine (VBLK/), 
and COLOR to determine which 


control signals to generate in the next machine state and 
how long the signals <;Ireto remain. 
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The horizontal 
state machine 
PROM generates 
the 
following signals: 


PHI2 
PH2 
PHI 
PNEXTV 


PHBLK/ 
PH SYNC/ 


Duration control bit 
Duration control bit 
Duration control bit 
Next vertical count, occurs at twice the 
horizontal line rate 
Refresh enable for 3242 and two port 
logic 
Shift register enable to load data, 
address counter enable 
Horizontal blanking control 
Horizontal synchronization (drive) 
control 


The prefix "P" 
on each of the above signals indicates 
that the PROM is a source of the signal. Since all out- 
puts of the PROMs are allowed a full ADV cycle (16 
PIXCLK periods) before they are required to be stable 
there is no critical access time requirement for the 2716s. 
With a 10.0 MHz clock, 1.6 microseconds are available. 


A 74S374 pipeline register, clocked by the rising edge of 
ADV, holds stable control signals throughout 
the next 
ADV period. 


The vertical state machine is constructed in the same 
manner as the horizontal one except that an additional 
74LSI63 counter is used to extend the duration capabili- 
ty of the machine. The vertical control PROM produces 
the following signals: 


PVBLK/ 
PVSYNC/ 
PV224 
PVI6 
PV8 
PV4 
PV2 
PVI 


Vertical blanking control 
Vertical synchronization (drive) control 
Duration control bit 
Duration control bit 
Duration control bit 
Duration control bit 
Duration control bit 
Duration control bit 


As the vertical state counter reaches the terminal count 
(VPC3... VPCO= 15) the signal FIELDO/ 
is asserted 
which causes the horizontal state to be set to zero. This 
guarantees that the phase of the two machines is in syn- 
chronism. FIELDO/ also preconditions the signal ODD 
to zero in preparation 
to entering the first of the two 
fields of each frame. 


The contents of the two PROMs required to interface to 
an NEC Model JC-1202 DH color monitor or a Ball 
Brothers TTL-120 monochrome display are included in 
Appendix D. The timing diagrams i'nAppendix C repre- 
sent the PROM information in a more graphical man- 


ner. Using these two control PROMs, one of the two 
displays is generated: 


262 line color display, non-interlaced, 
with 240 
visible scan lines, 256 pixels per scan line, 4 
bits/pixel. 


525 line monochrome 
display, illterlaced 2:1, 
with 480 visible scan lines, 512 pixels per scan 
line, I bit/pixel. 


Of course with other PROM codings and crystal fre- 
quencies, different display formats and monitor control 
signals are possible. 


The MULTIBUS<!larchitecture's 
full megabyte address 
capability allows direct mapping of the 64K bytes of the 
frame buffer RAM on to the system bus. In similar dis- 
play systems designed for traditional minicomputer bus 
structures or early microcomputers 
some form of ad- 
dress mapping or bank selection was usually necessary 
since the address space of those machines was limited 
(64K to 256K bytes). 


Two 3205 decoders examine the MULTIBUS<!laddress 
lines ADR13/ ... ADRF/ 
and the RAM inhibit signal 
INHI/. 
A 74S32 gate and two jumpers allow each 32K 
byte frame buffer RAM ("A" and "B") 
section to be 
placed at any 32K byte boundary in the one megabyte 
system address space. 


Three 8286 bus transceivers are used in the byte swap- 
ping configuration 
to buffer the onboard 
16 bit wide 
bidirectional 
data 
bus from the MULTIBUS<!llines 
DATF/ ... DATO/. 


Four 74S74 flip flops are sequenced by the two port con- 
trol logic to synchronize MULTIBUS<!lrequests to the 
on-board timing. The four stage pipeline is initiated with 
the receipt of memory read (MRDC/) or memory write 
(MWTC/) commands. If the board is selected (BDSELI 
low) when CMD strobes the first flip flop, service to the 
request from the MULTIBUS'" system bus is begun. On 
the rising edge of SRTIME (start of state S7) an arbitra- 
tion flip flop is strobed to synchronize the bus request to 
the on-board clock. One state later a second arbitration 
flip flop is clocked to minimize the possibility of error in 
the synchronization. 
This third flip flop produces the 
signal BUS which is aligned with state S8 and specifies to 
the two port control logic that a MULTIBUS<!laccess is 
being serviced. The memory array is sequenced just as 
for a video refresh cycle. In the case that the CMD is 
actually a write operation, 
one or more of the signals 
WRRED/, 
WRGRN/, 
WRBLU/, and WRXTRA/ 
are 


a~ll:~U 
WI: memury array ana cause me cycle to oe 


either a single byte write to the high or low byte of the ar- 
ray or a full 16 bit store operation. 


At the end of any MULTIBU8C!)port cycle the signal 
LATCH is produced 
which performs two functions. 
First, LATCH opens a 748373 transparent 
latch and 


then closes it to capture the data on the RAM data out 
lines. In the case of a MULTIBU8C!)read, this data is 
returned to the bus, and in the case of a write, it is dis- 
carded. Additionally, the falling edge of LATCH clocks 
a flip flop which clears the bus synchronization flip flops 
and forms XACKI, thus informing the MULTIBUSC!lmas- 
ter that the transfer has been acknowledged. 


The video output section of the display controller forms 
the three primary signals required by conventional raster 
scan display 
monitors: 
blanked 
video data 
(RED, 
GREEN, and BLUE for color), horizontal drive and 
vertical drive. 


When used to control a monochrome display, the video 
data from the frame buffer memory may be displayed in 
normal or reversed mode. In normal mode a logical one 


m the !rame Outter generates white pixels and a logical 
zero generates black pixels. In reversed video mode a 
logical one in the frame buffer memory generates black 
pixels and vice versa. 


Regardless of the video mode chosen, the pixel stream is 
properly blanked (by HBLKI 
and VBLK/) before it is 


presented to the monitor. HBLKI blanks the video infor- 
mation during the horizontal retrace time and VBLKI 
blanks the video during the vertical retrace interval. 


A final 748175 register, duplicated for the color and 
monochrome output sections, removes any skew and jit- 
ter between the video pixels and the synchronization 
signals and also affords the user the option of selecting 
the polarity of the synchronization signals. In the case of 
the NEC color monitor, 
a combination 
of horizontal 


and vertical synchronization signals is required. Finally, 
the selected output signals are each buffered by a 74128 
line driver suitable for driving the low impedance (50 to 
100 ohms) terminated 
lines which are preferred 
for 


transporting these signals. The 74128 drivers are actually 
50 ohm 
drivers 
and 
for driving 
lines with higher 


characteristic impedances it is proper to add the ap- 
propriate series termination resistor. 
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APPENDIX 
D 
CONTROL PROM CODES 


cIC 
OBJ 
dltE 
SOU~:E STAIDIENT 
LOC OBJ 
LINE 
SOU~E STAID'£"lT 


i , 
Hor,Zooti' 
=''0' 
Codes fOr I'C..TJ9JS 
CrilE 
9I.Jff~r 
lIIl[illI 
78 
db - 


li'IlSfD 


I1G 
IIlI 
79 
db - 


L'Nl6fD 
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IIlI.lEIIlI 
IIil 
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u~.5EIl 
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+----- 
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_1IlI 
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d, -., 
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1+------- 
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11+------ 
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P'lO!'! :nDut VUlib~es 


7 
111 .•.---- 
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!I!I+------ 
IV. 


_illI 
C9 
db 
a_ 
, UIll£ED 
'0 
Ii 111+------ 
01/'2 


i1IlIElIlI 
38 
db - 


, UIlm 
II 
Iltl!:I 
.•.... 
-- 
:'\11 


_Ill! 
31 
-- 


, LlOlHD 
.L 
765;.:':'~11! 
°0 
DiU Out'tJts 


.111f1l 
". 
db 
iil_ 
, 3 
" 
;111 
: 


1IlI11E9 
J3 
11l1l10Blb 
, I 
.4 
,,' 
: rl'QU red 'Ot:r,~ for 
'lE'llt StitE' 


a812a:l 
34 
1&!l81b 
:. 
:5 
-------------·-----------------B!.cI(/M~ltt' 
1:lOdE' 
1IlI13 !F 
3S 
" 


lBOOlIl!b 
, 4 
_2A 
16 
db 
00laIBI~ 
'22 
1IlI14 !F 
J5 
ob 
!.ll~lb 
:. 
8881 Sf 
17 
" 


01Blllllb 
:22'5 


~15 
EF 
37 
ob 
1110111!b 
, I 
1l'II::0f 
18 
db 
.1011111:1 
: 215 


illII6 7F 
38 
db 
01 ~11ilIb 
, 13 
"'83Fl 
19 
db 
il!Ue01b 
: 15 
1IlI17 !F 
39 
db 
I.HUb 
,. 
_Fi 
III 
db 
:.1l1liJeelb 
., 15 
1IlI18 EF 
48 
db 
!li01Hlb 
: I 
illIIl5 F' 
~I 
db 
llllll!:'b 
, I 


8819 EF 
., 
1110:111b 
, ! 
_It: 
2: 
Ob 
0111: lilJb 
,. 


IIlIIA EB 
42 
db 
!:i.010!lb 
: I 
8IIIl7 6E 
'" 
cb 
0l!B!lIeb 
; 18 


illI1B 81 
43 
db 
lill!iBHb 
, 3 
IlIIIllll 
" 


,b 
081~H1!!b 
, 22 


illIlC IIlI 
44 
db 
_b 
, tJf.ID 
IlIlIl9 7F 
15 
db 
1I11l1l!llb 
, 


1lII1DillI 
45 
db -- 


, UitJ5ED 
_Sf 
16 
d' 
0111111110 
, 225 
IIlIIEIIlI 
l£ 
db - 


, UOIl6ED 
1lIIIl0f 
17 
ob 
WHl111b 
, 225 


illIlF illI 
47 
db -. 


; UtfUSED 
\BtFI 
28 
db 
llllMlb 
, " 
48$e~kt 
illIlIlFi 
2'l 
db 
l111INfb 
, is 
49;------------------------------Co:.,r 
fIlOal? 
_FC 
JII 
db 
1l!1.1Bilb 
;. 
1!lI28~ 
se 
db 
:11_ 
, . 
_6E 
~l 
ob 
0111l!l!1i!b 
18 
1!lI21 E9 
51 
db 
l:leHlll!:l 
: , 
32;------------------------COlor 
~i!' 
I!lI22 89 
52 
1.!B111b 
" 


illIlB illI 
J3 
" - 


; t.:nllSeC 


IIlIZlIII 
53 
db 
•• 
!II!!b 
,. 
"11 
i!II!I 
34 
Ob -. 


; 
tillUSM 
I!lI24 88 
54 
cb 
:BHHb 
,. 
1IlI12 illI 
35 
db - 


; 
unused 


I!lI25 EB 
55 
ob 
~:a!:elb 
: I 
IlJi!l1~~ 
36 
db - 


: unus@o 


I!lI26 18 
56 
ob 
0!H!01~b 
, 13 
illIl.illI 
!7 
db - 


; 
unus.?d 


1!lI27111 
57 
c, 
IB091011:l 
:. 
"'15ill1 
38 
db O_ 


j 
un'JSed 


I!lI28 EB 
5S 
db 
j :!010:1b 
, I 
8816 illI 
'0 
db -, 
; 
unUSed 
I!lI29 EB 
59 
:llBlelll:: 
: 1 
illI17ill1 
.~ 
db O_ 


j 
uniJSed 


llI3l 
£9 
liD 
" 
:E01~lb 
, 
illII821 
Ai 
db 
~1010il!t1 
; 31 
I!lI2B BI 
61 
db 
l'l:Hb 
: 3 
illII9 7F 
.a2 
ob 
9111111:.!) 
, . 


mllll 
62 
db -- 


: iNHQ 
illIlA Sf 
.:; 
db 
0!'H!!1~!l 
. 225 


I!lI2OIIlI 
63 
db 
i_ 
, "'tEED 
illII8 IF 
•• 
ob 
llli!ll!!:b 
: :l25 
I!lI2EIIlI 
54 
db -- 


. L~ED 
IIlIIC Fl 
.5 
db 
~lli.lt1 
, i5 
I!lI1fIlll 
65 
ob - 


; UHUSED 
illIlO Fl 
46 
cb 
!!1:lMl!ltb 
, :5 


1!lI38~ 
60 
db 
l@lMe89b 
, . 
~lE Fj:j 
47 
,b 
1111i019b 
, 6 


0831 E9 
67 
db 
lUStBe:!! 
, I 
illIIF7A 
.S 
ob 
0111101IJb 
, 6 


illI32 SO 
68 
db 
:eeliHl01b 
,. 
49 
am 
!F 
69 
d, 
t_llll!) 
;. 
se 
VertlCi! 
PO 
Inp~t 
lJiriibltoS 
I!lI34 !F 
Jll 
db 
!.HUb 
,. 
51 


8135 EF 
71 
db 
1110i111b 
, i 
51 
'D.OR-A4 


I!lI36 7F 
72 
db 
01111111:1 
; 1:; 
53 
V'C 
• A3 
_iJ' 
73 
db 
iB.ll:b 
,. 
54 
Vf'C1 - q2 


I!lI38 EF 
74 
db 
1l1liHI~:b 
: l 
55' 
VPCi. 
• H' 


IlIl9 
EF 
IS 
do 
llHHll!b 
: 
1 
56, 
vPCa 
- "0 
IIlI3A£9 
76 
ob 
J !101l111b 
, I 
57 ; 
8Ql81 
77 
db 
I0ll.1ll 
, 3 
- 


5S 


7·55 
AFN.Q1948A 


inter 


APPENDIX 
E 
PL/M·86 GRAPHICS 
SOFTWARE LISTING 


ISIS-II 
PL/II-II; VI.2 
C1JIf'ILATHIf Of IOXJlE PIXEl. 


OBJEI:TIIllU.E 
PLAlEl IN Pixel.OBJ 
ClllPILER IIMI<ED BY: :fl:.11186 pixel.STC 
LAn 
OPTl~II£(I) 


/. 
ThiS Ft/ ••...96 PTonM 
dNOnstrites 
the use of 
iI nUMberof 


prilitive 
IJu.Phicsroutines 
used to drivt the ftllTIIlJS 


Tister niPhics controller 
~rd. 


There ue 
five 
/liin 
i1rfiS 
to 
this 
PT09r•• : 


1. DeClifi.tions 
for 
viriibles 
ilnd Pelnon 
diU 
structure. 


2. Loot-level 110 procedures for ~"" SBC-Sli/l2A. 
3. The!r~hics 
routines. 


•• 
Turtle: 
• siMPle 
!lTiPhics 
input 
dev:ce. 


5. 
The •• 
in 
bOdy, 
lliinly 
i SIMPle 
COfl*ind 
d~oder. 


declin' 
(x,'f,Slze) 
iddressi 
etecliiTe true literilly 
'8ffh'i 


declarefillse literilily 
'.,.,.; 
declnf cr literilty 
'lBiIh'; 


dPclire 
If 
I iterillY 'il!dh' i 


/. 
SIlC-B6/12A constints fOT8251 l.5ART Sial us ond Dati ./ 


deelirf usUt 
literilly 
'lIdih'; 


deC lire 
UdiU 
I iterill 
'f '1:tBt,'; 


,* 8251 status 
- Te<eive buffer 
fUll.triinSiit 
buHer 
eMPty *1 
deCIUf 
rxbf 
I iterilly 
'8I2h'; 


declare 
tXbe literid 
I' '1I1h'; 


declUe- 
si,non 
(*) 
b,te 
initiil 


(crolf,'lt1.TUlJS 
GrIPhiCS APPliCitiOll 
Note S,stell', 


'4/2111981',cr, 
If); 


deClirf 
turtlehflp 
(.) 
byte 
initiil 
/* help 
fi If 
for 
the 
turtle 
fiCi Iity 
*/ 


( cr,lf. 
'i - AddVertex',cr,lf, 


1 c(s) 
- Cr•••ISCIferd', cr, If, 


'd 
- TurtleDJwn',cr, 
If, 
'e - EndPol Y!On', cr, 
t f, 
'h - Help',cr,If, 
'I - Turtl(lleft',cr, 
If, 


'n - Wd..set', 
cr,lf, 


I r - Tuft IfRilJht', 
cr, If, 
's 
- StirtPolY9On',Cr, 
If, 
'u 
- TurttfllP',cr, 
If); 


deClif'f' 
Mlinhe-Ip 
(*) 
b,te 
iftitiil 
/* help 
file 
for 
the ain 
pr(llJr. 
loop */ 
( cr, If, 


'i<M){Y) 
- AddVtrtex a X,Y',ef,lf, 


'b(C) 
- Select 
color c',cr,I1, 


'c - CINr',cr, 
If, 
,e - EndPol non', 
cr, If, 
'fb)()') 
- FintiSY i x,,',cr,lf, 


'h - HfIP',CT,lf, 
, i (1) 
- 
Ink With font 
f', 
cr, If, 


'I - OutIine PoIYlJon',cr, 
If, 


'.(x) 
- f10de Selection 
x', 


'. 
or, 
1- ind 
not, 
2- xor+' ,cr,lf, 
'n(x) 
(y) 
- NetEdlJe6et a X,Y' ,cr,lf, 


'l:!- 
Fil IPOI'!Ofl',Cr, 
If, 


Iq 
_ Toni. COlor/tIN bOOlNn',cr, 
If. 


's(x)(y) 
- Stirt 
PoIJ9OfI a x,Y',Cr,lf, 
't 
- Turtle',crdf, 
'1- 
Setup 
Piturn 
1',cr,lf, 


'2 
- Setup 
Pittern 
2',cr, 
If, 
'3 - Setup 
Pittern 
3', cr. 1f, 


'4 - Plot 
Color 
Pitt,rn',cr,lf, 


'? - Show PoIYlJon Diu Structure',CT,If,cr,lf. 


(PiTue-ter) 
- IieXid@CilYl Pi;ril@ter 
" 


'terlil\ited 
b, 
i sNce',cr,lf)i 


deel,ue 
Mlinprc.t 
(.) 
bYte 
initiil 
('f1iin: 
')j 


declir. 
turtl8rotlPt 
(.) 
byte 
initiil 
('Turtle: 
'); 


deCliTe 
colorprc.Pt 
(*) 
byte 
ilitiil 
(cr,lf,'Color 
It)de')j 


decliTe 
tMJrOMPt (*) 
byte 
initiil 
(cr,lf,'S'" 
Pbdel); 


/. 
The PO..YOON diU st rocture ./ 


deClue 
d(edWlilit) 
iddTe'Ssi 


dec liTe 
YI!(edge1 ilit) 
iddressi 


decliTe 
x1(ectWI ilit) 
iddTt~ss; 


decl,ue 
yl(fdWI 
ilit) 
iddress; 


/* dPrived vilues 
*/ 


deelue 
ilCtiwe(fdtfl 
i.it) 
brte; 
/* true 
if 
edIJf is 
ill the ietiytl 
list 
*/ 


dlKlif'f' 
xri,ht(edtel 
i.it) 
byte; 


/. true if xl (=x2./ 
dee lirf 
tIOredX(ed,el 
iMit) 
b,te; 
/. true if ilIs(SI••• ) is ( 1/2'/ 
declire 
xi nt (edlJe I i.it) 
address; 
/* the x-int,rceP't 
of the sCinline 
.ith 
this 
ed!e 
*/ 


dec lue 
delx(edWl 
i.lt) 
iddress; 
/. 
abSOlute vilue 
Of x2-xl ./ 


declue 
deoIY(edWli.it) 
iddressi 


/. 
abSOlute va' ue Of v2-vI ./ 


decliTe 
rett(fdWl 
i.it) 
iddr~si 
/* the 
'rNiinder' 
in the 
error 
Vii ue */ 


decliTe 
UP(erdwl ilit) 
iddress; 
/* uP/dOWI fl., 
for 
ori,in.1 
HtJf *' 


/. 
tNo 
pointers 
into 
the 
diU 
structure 
*/ 


decl.re 
(POlredgeS,thised!e'5et) 
iddress; 
/* POIYedlJe5 = POintfr 
to 
list 
v., id edw */ 
'* thised9fSft 
= POinter 
to 
the 
stirt 
of the 
CUrTtlnt edlJe set 
*/ 


inter 


1* the plottint 
.cde 


~t 
l=CIPU, 
2=COIPINtnt, 
3••• 2S5=? *1 
dec lire 
plotllOdf byte; 


declUt 
fOntb1te5 (*) 
bY'te inilii' 
,* 
ThiS is 
just 
i silPle 
nTi.Y 
of Ntterns 
O'f bytes Nhlch 
n@ used whenfillin! 
•. recUnJuln 
or Paino".' 
iTS. 
Just ~ 
NSi I)', 
this 
could be TePliCed Mith MJ1I,iI chirieter 
NtterM. 
BeC..,5e the displn 
controller 
displiYS 
ae.;lTY 
diU 
SUT1in9 Mith the IfiSt silJnificint 
bit 
thrse Nttems 


MiII 
be reversed 
(ilon, 
the X-UiS) 
frOM 1'10 
•• they iPPNT 
here. 


*, 
( 


11I1I11Ib. '* ootte", 
1 *' 
llllllllb. 
11l1l111b. 
lllllillb, 
11111II lb. 
11111111b. 
111ll1l1b. 
ll1l1l1lb. 


11IlI1•••• 
,. Pittern 
1*' 
111111&, 
1I111111llb. 
IlIll111b. 
111l11-., 
IIBI8>. 
181_lllb. 
.llII1b, 


BllII1b, 
'* ••nern 2 *' 
181_lllb. 
iI_lil1lb, 
111l1111l111b, 
11I11tl8lb. 
10I1llII1&. 
11_1IlIb, 
11IlII!1lll!b, 


1811111&. '* Pittern 3 *' 
1lllllllb. 
1118111&. 
11118101b, 
1818111llb, 
11118181b, 
I0I8111llb, 
1111811lb. 


11I18IIllb. 
/* Pittern 4 *' 
18I1I1IIlb. 
11I111il1lb. 
1111111&, 
1111118>, 
18111"', 
1IllI11IIlI8b, 
IlIlIIllIIlIb. 


1111l11111llb.'* ••ttern 5 *' 
IlIIlllllb. 
1111118l1b, 
11111111&. 
11111111&. 
11I1I1I1b. 


41 


42 
43 


•• 


45 
47 
48 


49 


51 
51 
2 


53 
2 


54 
2 


55 


Sli 


59 


6lI 


61 
62 
64 
65 


66 
I 
67 
2 
68 
2 


69 
2 


71 


71n 
73 
2 
74 
2 
75 
2 
76 
3 
77 
3 
78 
2 


75 


8ll 
2 


SI 
2 
82 
2 
83 
2 


84 


85 
86 
87 
88 


8'.l 


91 
91 


7-57 


ll1l1l11lb. 
11111111& 


); 


'* the FBi""'5 *' 
decliTe 
FBII <l63llo\) idd ••••• it (•••• >; 


dec liTe FBI <l63llo\l iddres. 
it (8IS_); 
'* SoMe I..o0o LeYel I/O Procedures *' 


ci: 
PTOCt!durf bytei 


/* !Jet •. chirieter 
trOll t~ 
coftsote input dtvice 
*1 


do While (input(usut) 
ind nbf){)rXbfi 
.ncB 


reotun,(input(ud.lU) 
MId I7fh); 


efId cii 


co: prOCedure(c~r); 
/* wriU 
c~riCUr 
to the consoleoutPUt device */ 


dec:lire chir byte; 
do Mhile (input(uSUt) 
MId 
tll~)Otxbe; 
end; 


Ol1tPUt(Uditi)=choir; 
end co; 


(its: 
procedurebyte; 


/* CheCkthe console device input sU:tus */ 
'* return true if 
chirKter 
iVii I~le *' 


,f (in..,t(.stit) 
i!1drKbf)=rxbl 
tf'E'1Iretum(true); 
else retum(filse); 
end cstsi 


up(~: 
procedtlre (c) byte; 


/* 
if cl\.lrieter 
c is lowr 
(~e 


theft return the uPPerCi5e wrsi on 
else return the' ori!inil 
chirieter 
*/ 


declire 
c byte; 
if (c)='i') 
ind (c<='z') 
thrn return(c-('i'-IA'»i 


else retam(d; 
end aPCISf; 


cr If; procedurei 
ull 
(o(cr); 
Cill 
(O(lf); 


end (rIB 


cstring: 
prOCedure(ptr,len)i 


/* print the string 
it 
the pointer lOCition *' 


dee/ire ptr POinteri 
deelire 
len idcfressi 


deel.arechirs bised ptr(t) 
bytei 


decl.are (t iddr~5; 
do et=e to len-l i 
(ill 
cO(Chirs(ct»; 


end: 
end (stringi 


byteout: procedure (b)i 
/* ootput byte b is two hfxldeciul 
~ricters 
*/ 


declue b brte; 
(ill 
coO•• KCOde(.hr«b 
iIld 811ll). 4»); 
Cill 
co(hexeade(bMId IiJtfh»; 


end bY'teouti 


\C)rlbJt: procedure (Ill i 
/* ootPI't • is four heXideCiAI chir~ter5 
*/ 


declire •• iddreossi 
cill 
byteout(hi!hhd)i 


cill 
byteout(Ia.(N» 
; 


end t«lrdoot; 


cOde:procecture(c)brte; 
'* convert the hexildeciMi.1 
iSci i chi.ricter 
to nibble Vilue */ 
declire 
c bytei 
declire d byte; 


inter 


92 
if (c)::'.') 
MId «((='f') 
then d=c-'a'+tSi 
172 
4 
~ 
or ShI(double(low(Pittern»,S); 


94 
else 
if 
(c)='A') 
and (c(='P) 
thPn d=c-'A'+tli 
113 
4 
wl=wl or shl<double(hilJt\(Pittern)),8J; 


$ 
flse 
if Cd:'g') 
and «((='9') 
then d=c-'I'; 
174 
4 
endi 


!II 
olse 
d=16; 
175 
3 
if 
blue then 
99 
returned) ; 
176 
3 
do; 
1111 
end cOde; 
177 
4 
w2=w2or low(Pittern)j 
w:s=.3or hi9h(Piittern); 


179 
4 
encH 


101 
NOrdin: procedUre address; 
1811 
3 
if xtri 
thl:n 


/* IiCCUlulite ~rPS'5 
PirMeter 
IS1 
3 
do; 
frOM console 
inpu1. 
device *' 
182 
4 
w2=w2or 5ht(double(10M(~ttern)),B); 


1B2 
2 
declare 
w ~ress; 
183 
4 
03=103or shl (dOUbIO(hl.h(Pittorn»,S); 
103 
2 
declire 
«(,ChiT) 
bJ1.ei 
184 
4 
encB 


104 
2 
.=8; c=I; 
185 
3 
wordidr=Shl (I«)rdidf,l); 


1116 
2 
do Whllo cO 16; 
186 
3 
do Ci5e Plot'MOde; 
107 
3 
IF5hICtllh4)+ci 
chn=cii 
187 
4 
dO; 1* CiSee - Erie 
Pattern with buHer *1 
1119 
3 
CIII 
co(chir); 
c=COde(c~r); 
188 
5 
F!lII(wordidr)=fBl!(wordidr) 
or 00; 


III 
3 
eneB 
189 
5 
F!lII(wordidr>ll'fll(wordidr>ll 
," 01; 
112 
2 
return(.); 
1911 
5 
FBl<wordidr)=FBl<wordidr) 
or .2; 


113 
2 
end wordin; 
191 
5 
FBl<oordidr>ll=FBl<wordidr>ll 
or 03; 
114 
I 
selMOde; PTocec:lUre(lIOde); 
192 
5 
endi 


/* se-t the plott i ft, MOde*/ 
193 
4 
doi /* ase 
1 - (!eu 
Pattern frOill buffer 
*1 


115 
2 
declare MOdebyte; 
194 
5 
F!lII(wordidr)=fBl!(wordidr) 
ind not oB; 
116 
2 
if 
fIIIOde)2 
then plotMode=2i else 
plotlOde=~ei 
195 
5 
F!lII(wordidr>ll'ffil(wordidr>ll 
ine not 0,; 


119 
2 
end SlltlOdei 
1$ 
5 
FBl<wordidr)=FBllwordidr) 
ind not .2; 


197 
5 
FBl<wordidr>ll=FBl<wordidr>ll 
and not "'; 
120 
set fOnt: proCeduTf (font); 
1!11 
5 
end; 


/* set the font 
Nttern 
nUMberused to f i I I arNS */ 
199 
4 
doi 1* case 2 - COMpleMentPittern 
*I 
121 
declare fOftt byte; 
2\ll! 
5 
F!lII(wordidr)=fBl!(wordidr) 
,or 
00; 


122 
If foIIt) Uo119th( fontbrtos)/S) 
thOn .lotfont=B; 
201 
5 
FB'HNOrdadr+1)=FB8(l«>rdadrt1)>cor",~j 
124 
else Plotfont=Shl(fant,3); 
2B2 
5 
FBl<wordidr)=FBl<wordidr) 
,or 
.2; 


125 
end setfont; 
203 
5 
FBHNOrdadr+t)=f'Bl(l«>rdidrtl) 
)(,)r ~3j 


2B4 
5 
endi 


126 
coIorcrt: 
prOcedure (bCK)!Un)i 
205 
4 
endi 


/* Is thiS for a Color or a BIll biter 
*I 
21!6 
3 
ond: 


127 
2 
deClare bOOlNI'l bJte; 
olse 


128 
2 
colorlOde=bOOlNni 
207 
do case pI otalOde; 


129 
2 
if colorfllOdethtn 
/* case 0 - 
Mer,e 
pattern 
.,ith 
buffer *1 
138 
2 
do; 
208 
F!lII(wordidr)=FBB(wordadr) 
or Pittern: 


131 
3 
call 
cstrin,(acolonITOIIP't,lenlJth(colorprOlpt»; 
/. 
Ci5e 1 - clear 
Pattern ffOftl buffer *1 
132 
3 
scrtenWidth-""'256; 
2119 
FBe(..:lrdidr)::fB(I(MOrd.dr) 
.nd not patto?rr:; 
133 
3 
screenhei9ht=248; 
1* case 2 - selectivelY 
COIPleftlent.,th 
Pittern 
>l:j 


134 
3 
eneH 
218 
FlIHl«>rdidr)=FB'HNOTdidr) xor pattern; 
olse 
211 
en,H 


13:5 
2 
do; 
212 
end MOdifyi 


136 
3 
c.11 cstrin,(ibM.rOll't,ltnfl:h(bWPrOMlt»; 


137 
3 
screenMid~12; 
213 
pterror: 
procedure (x. y) byte; 


138 
3 
SCTWnh!'i9ht=4BIi 
1* check if 
the POInt x,y is in raMe of the 5ereen *1 


139 
3 
endi 
1* report on the console if 
error 
*1 
14ll 
2 
end colorcrt; 
214 
2 
declare (X, y) addressi 
215 
2 
if 
(1l)=screenNidth) or (y):;sereenheisht) 
'then 


141 
wtcolor: 
DroCfc!ure (Calor); 
216 
2 
do; 


142 
declare Color byte; 
217 
3 
call 
cstrinlJ(iPointerror, 
len9tt-e(POlnterror» i 


143 
if 
(color 
and .1"') 08 then red=trUf; 
else red=false; 
218 
3 
call 
NOrdout(x); 
call 
co(','); 
eal! 
worC'Jut(Y)i 


146 
;f (COlor ind I112h)00 
221 
3 
call 
crlf; 


theft lJTetn=true; else lJf'elen=false; 
222 
3 
return 
truei 


149 
if 
(color 
i11d BI4f,) 00 
223 
3 
end; 


thel 
blue-1:rue; else bl ue=falsei 
224 
2 
else 
return filse; 


152 
If (COlor ind IIIllh)(10 
225 
2 
end pte rfa r; 


then xtri=truei 
else 
lltra=:false; 


155 
end seteolor; 
226 
plotpt: 
procedure (II, y); 


/* plot 
Ii sin,le 
Pl)(el it 
the point 
II!Y */ 
156 
lOtify: 
procfdUre(wordidr,Pittern); 
227 
2 
declare 
()II Y) address; 


1* MOdify true 
buffer 
location With Pattern *1 
228 
2 
declare(Pidr,p)l!py) 
iddressi 
157 
declare 
(l«>rd~r,Pittern) 
~dress; 
229 
2 
declare 
(PUSk) address; 


158 
declare <",wl,w2,M3) 
addressi 
238 
2 
declare 
(pct) 
byte; 
159 
if 
colorlllOdethlMl 
231 
2 
if 
pterror(x. 
y) tt-.en returni 
1GB 
do; 
1* set bit 
zero *1 
161 
.,.; 
01=0; 02=0; 113=8; 
233 
PMisk:;1; 


165 
if 
red then 
234 
pct=IOW(x) and Ifhi 
166 
do; 
235 
if 
pctOi 
then Ptlask:;rol(PMdSk,:Jet); 
167 
NI=wI or low(Pittern); 
237 
if 
colorftOde 
1GB 
wt~l 
or hi!h(Nttern); 
thOn 
Padr={Shl(y,S) ind e1f~h) 
or (Stlr(lb4) 
ind 0fh); 
169 
end; 
239 
0150 Pidr=(Shl(y,5) 
and 03foBh) "' 
(shr(x,4) 
i"d 
81fh); 
171 
if 
lJTeen 
then 
240 
call 
lOdify(padr, PMiSI(}; 


171 
doi 
241 
end plotpt; 


7-58 
AFN·01948A 


in1:el 


242 


243 
2Il4 
245 


247 
252 
2Sli 
2S7 
262 


266 
267 
271 
2n 
273 
215 
277 


278 
279 
281 
281 
282 
283 


284 
285 
2116 
287 


288 
289 
291 
291 


292 
2 
293 
2 
2SO 
3 


295 
3 


2$ 
3 
297 
4 
2"Il 
4 
29S 
4 
3lll! 
3 
301 
3 
3114 
3 
3115 
2 
3llS 
2 
307 
3 
3118 
3 
3119 
3 
311 
4 
313 
4 
314 
4 
315 
3 
316 
3 
317 
3 


319 


3211 
321 
322 


323 


ddi: procedure (xl, 11,xl, 12); 
/. 
The Di1.til 
Different:.1 
AnalYZer */ 
'* Generites 
Ii line SMEnt 
frOM xl,11 
to x2, '12 *1 
'* Uses BresenhaM's 
AI90ritNh 
See Newaa.n 
and SProull *' 
de<:lare 
(xl,YlIl12,)'2) 
iddressi 
dec lire 
(i I X,y, del x, del y, del x2, de I)'2, nth diTeet ion) adcHessi 


if pterror(xl,yl) 
or P'terror(x2,Y2) 
then return; 
'* sort the coordiMte NiTS *, 
if 
'11)Y2 'Chen do; 
,=)'1; 
11=12: 
12=y; 
x=xt; 
xl=x2i 
X2=lli 
end: 
dely:,2-yli 
if x1)x2 then do; delpxl-x2i 
direction=1: 
end: 


else do; del)F1l2-Mli direetion=t; 
end: 
'* one SPeCial 
casel 
the 
U«:l endpoints 
are 
eQual t.j 


if (do'x=ll) 
ind (dOIY=il) then 
dO; Cill 
Plotpt(xl,yl); 
return: 
endi 
dol M2=shl(dolx. D; 
dely2=sh1 (del)', 1); 
y=yl; 
ll=lC1i 
if dely(=delx 
then retFdely2-delXi 
elSf 
retFdelx2-delYi 


'* i hOrizonUl 
line, 
.oother sPecial (ise *' 
if delY=il then 
doi 
if 
dire'tion~ 
then 
d<l ,;,1 
to xl; 


'ill 
Plotpt<Jh 11)i 
end; 
olse 
dO )1=)12to xl; 


'il 
t 
PlotPt(X,11); 


'* i vertiCil 
I ine, another sPecial case t/ 
@Ise if delx=l 
then 


do F11 to y2; 
cill 
Plotpt(xl,Y); 
end; 
,* execute the deli accordiM to 
1he relitive 
sizes Of dtlx 
and delY *' 
else if 
deIY(=delx then 


do i=l to delx; 
Cill 
PI01pt(X,Y)i 
if r•• (327li8 then 


dO; 
y=y+l; 
rett=rett+delY2-delx2; 
end; 
else fett=rN+dely2i 
if 
di rection=fJ 1hen x=x+l; else x=x-t; 
end; 
else If deJY)delx U..en 
do i=l to del yi 
Cill 
Plotpt()I,y)i 


if r•• (327li8 then 
do; 
if 
di rectlon=l 
then x=x+1; else )(=x-l i 
fetFrN+del x2-dely2i 


1!f1d; 
else re.=rM+del x2i 
y=y+1; 
end; 


end ddii 
inklll'le: 
procedure (xllx2,ysc.in); 
,* Ink ill 
points on hOrizonta.l scan line ysc.tn*' 
/. 
betloeen X-COOrd,nit•• xl and x2 ./ 
declare (K!,x2,ysc.tn) 
addressi 
declire 
(xNard,left"5)h 
r i'htMiSk,5tIPPleJ 
iddressi 
decl.tre 
(1(1 pxl, px2,c1"«lr~r) 
.tddressi 


32:5 


32li 


327 
328 
329 
331 


332 
333 
335 


336 
338 


339 
341 
342 
344 
345 


347 


349 


35Il 
351 
352 
353 
354 
355 


356 
357 
35ll 
359 
361 
361 
362 
363 
364 
365 


366 
367 
368 
371 
376 
377 
378 
379 


388 


381 
2 
382 
2 


384 
2 
385 
2 


386 
2 
387 
2 


3118 
2 


389 
1 
3'311 2 
391 
2 
394 
2 


396 
2 
39Il 
2 


,* CJe1the ~PTopriilte 
pattern to fi! I this 
scan I ~ne*1 


stiPPIe=fontbrtes(Plotfont+(yscan 
Mtd ]»; 
'* Mike it 
a 1S-bit QUin1ity by byte repl iCition *' 
'5t ipple=s1i gple+shl(st IPPlei 8); 
/. 
sort 
xl and ,2 ffJr do 1000 ./ 
if x1)xl then 


dO; 
pI(1=x2; px2=xli 


1!f1d; 
olse 


dO; 
pxl=x1; px2=x2; 


end; 
'* cOIPU1e1he lOrd index in10 the S(in 1ine *1 
if 
colorlOde 1hen xNOrd=(Shr(px2,4)-Shr(px1,4» ind 8thi 


olse 
_rd;(Shr(ox2.4)-Shr(0x1.4» 
ind Blfh; 


'* MaskslIliII be used for 
the possible Pirtial 
IIlOrds 


it 
the left 
and ri,M 
Of the UN to be inked *' 


lefwSi<=lIffffh; 
ri.htlliSk=lIffffh; 


,t;loo(oxD 
ind Bfh; 


if cH)B then 
10ftlislr-shl(loftliSk.ct); 
,t;loo(ox2) 
ind Bfh; 


if <t015 
then ri.htIiSIr-Shr(ri.htlisk.<l5-ct»; 
'* fOrM lhe frMe 
buffer 
index Of the first 
cnd *' 


if 
colorllOde 
then .,rdidr-(shr(0x1.4l 
ilId Bllfhl 


or (sh I(1SCill.5) iI\d II foBh); 
olse .,rdidr-(shr(oxl.4) 
ilId Ilfh) 


or (shl(YSCill.5l 
iIld I3foBh); 
if JCNOr~ then 
d<l; 


rilJhtuSk=ri9httYSk 
and lefwi5k; 


Ieft •• sk=r ilJhtMas«; 
cill 
MOdifY(NOrdidr,ri,httY,SfI:M'idstipple); 


endi 
olse 


dO; 


cill 
lOdifY(NOrdidr,leftIliSK 
ind stiPPle); 


if x.,relll 
then 
do ",,1 to ('NOrd-I); 
call 
a:ldifY(MOr$dr+x,SliPcHe); 


end; 
(ill 
MOdif1Ctr.ordldr+I(MOrd,rilJhwskand stiPPle); 


end; 


end inkl inei 
plotrect: 
procfdurehl. 
11,xl, yl); 
'* plot iI'l Ue.J 
filled 
rectin91e as ~cribed 
by *, 
'* the dii'Jonal "111 xl, 11 usiM the ,Iobal 
Oh?5*' 


/. 
01cn.ode iIld olotfont 
./ 


declirf 
(xl,yl,xld'l) 
iddressi 
declire 
1 iddressi 


if rnrror(xed1) 
or P'terror(x!,yl) 
'then return; 
if 
)'8»)'1 then dO; )'=11; y~)'1i 
Yl=,.; 
end; 


do FyI 
to 11; 
call 
inkl ine(lIl, xl, y); 


eneH 
end plotrect; 


I inerect: 
procedure (xl,11,)I2, ,2) i 
'* gpner.te a lint 
drawin, Of the recUnlJle *' 
'* deScribed by the dii9Of\il 
xl,y1 
X2,12*' 


declire 
(x!,Yl,x2,Y2) 
address; 
if 
Pt:errorh:1,)'1) or crterror(x2,12) 
then return; 
cill 
ddi(xl. 11. ,2. 11); 


cill 
ddi(x2. 11. ,2. 12); 
cill 
ddi(xl, 12,x2, 12); 


cill 
ddi(xl. 11. xl. 12); 
end I inerec1; 
ShOtEdn: procedure(e); 
decliTe e iddressi 
'ill 
.:)Tdout(e); 
cill 
CO(':'); 
(ill 
CO(' '); 


CilillOrdout(xI(e»; 
c.ll 
Co('l'); 


'ill 
.,rd<lut(YI(oll; 
~II 
col' 
, l; 


'ill 
.,rdOClt(xHell; 
WI 
00('.' 
l ; 


•• 
2 
1112 
2 
•• 
2 
• 
2 
4llll 
2 


.e!l 


ue 
U1 


413 
414 


41~ 
416 
m 


418 


419 
421 


422 
423 
424 


425 
426 
427 


429 


429 
431 


432 
433 
434 
43S 


436 
437 
438 


439 


441 
441 
442 


443 
444 
447 
448 
449 


4511 
451 


452 


453 
3 
451 
3 
45:i 
3 


456 
457 
458 


459 


Cill 
lOlrdotrt(,l(e»); 
WI 
coC' 
'); 


'1I11 .:Jrdout(delx(e»; 
'.'1 Co(','); 


cill 
lOlrdotrt(delJ(e»); 
all 
coC' 
'); 


'till mrdout{r •• (e»; 
ell I eflf; 


end stGfdW; 


5ti,r1POIY: 
procedure hi Y); 
'* ~n 
I ntW SID Inon 
diU. st ructu re *' 
decllTe 
(x, y) iddTfSSi 
if I't.rror(x, r) then return; 
'* init 
thl 
WJ ,IObiI 
indexes into the dl.U structure 
., 
001-=41: 
thisedwset'f; 
/. 
""I 
tile 
fi rst 
vtrtex 
./ 


,'C""I~"")=x; 
,.c 110IJedoes) =,: 


end SUrtDoly; 


A:tdwrt.x: 
procedure (x,)'); 


1* ~d 
vertex 
to the current edlJe s,t 
of tl'le POIY9on*' 
deelire h:,1) iddress; 
if CJterror(lh y) 
then return; 
/. 
c_lelo 
lho second 
vtrte. 
of tho 
lost 
ed •• 
*1 


.1(001~''')=': 
,1(001~"")='; 
I)()I YedWS=ooI Yed,es+l i 
/. 
idd tho 
fi rsl 
vtrle' 
of tho next 
t<Ke *1 


,.COOIJed •••• )=,: 
'.COOI~ 
•••• )='; 


end iddvertex; 


newedwset: 
prOCedure(.,'!); 


/* 1fr.iute 
previous 
edge set ~d surt 
a neNone */ 
decllre 
(x, y) 
iddressi 
if I't.rror(x, 
y) then return; 
'* like the I~ 
vertex of this ed'R the sue 


i5 
the 
first 
veT1ex of this ed9e5e't, 
tMrebr 
clOSin, ttoe poI non 
on itself. *' 
'1(001'ed 
•••• )=dCthised9tSOl) 
: 


,I COOl~ 
•••• )=JIClhi sed9tSOl): 


pol Yed'Je'5=p()1Yed~tl; 
thi~t=ooIYedlJe5; 
/* insert the fi rst 
vertex of the newedgeset */ 
xl(POIYedWS)=Xi 
,1(POIYedws)=y; 
end~t; 


endPOIY: procedure; 
'* finish 
the 1m edlJeSft Of the POIY9on., 


declire e iddress; 
,ICool ,ed •••• )='ICthi 
sed •• set); 


,I (""IJed9K)=yICth 
isod •• set); 
/* 
Closed 
Off 
li51 
ed'Je 5.1 
*1 
'* SiPtUP/downfl., 
on the icculIUlited 
pOInon ed'3e5*1 


do e=I to poIYedges; 
if 
,1<o))"'Co) 
Ihtfl 
up(e)=lrue: 
olse 
up(o)=fOI""; 


enet; 
end endllOl)'; 
fi IIPOI,: 
procedure; 
'* irN 
fi II the POI)'9OI1speciiied 
bYdita 
5tructure *' 


declire 
(x, Y,liStptr) 
addres5; 
declire 
(ed~1 p,pue. PUll Pkl,px1lllinxd.inYdW-XY) iddress; 


nextpt: 
procedure Jddressi 
'* iCQuire next iet ive x- interceI't pt frOI poly!On*' 


declue 
(p,ptr,.x) 
address; 


P'tr=edgel 
i.it; 
Ix=screenMidth-li 
'* sc~ 
POlnon edge I ist 
for 
leftMost ictive 
pt *' 
dO Rl 
to 
110"ed ••• : 


if 
listptr{)edgeli.it 
then 


dO;'* discud 
dUl'liute 
points 00 edge5*' 
if 
(xint(p)=xint(li.stptr») 


and 


461 
462 
463 
467 
468 


471 
472 
m 


474 


476 


477 
478 
479 
481 
481 
482 
483 
484 
485 
486 
487 


4B8 


489 
491 


493 


4~ 


496 
497 


499 
5llI 


S02 
503 


505 
S06 


507 
SIll 


50!l 


51! 
512 


513 
3 


~14 
4 
~15 
4 
~16 
5 
517 
5 
518 
5 


~19~ 


7-60 


/* lho 
lints 
••••• 
lho ••••• 
51•••• / 
,* or one of thett is hOrilOOti.1 *' 
( (upCp)=up( l;I5tplr)) 


or 
C(deIJCp)=I) 
or 
(del,(fa5totr)=I») 


theoni.ctive(p)=fi.lsei 


eRe'; 
if 
ictiW(P) 
inet (IIint(p) (u) 
then 


dOi .x=xint(p)i 
ptr=pj 
endi 


end: 
if 
ptr()edWl 
iMit then iCtive(ptr)=Ulse; 


/* 50E 
side effects 
of this 
procedure*' 


.inx=tlxi 
listnr=Ptr; 
retum(ptr) 
; 
end nextllti 


'* PrePiritorY 
MJrk to eich POlJ9oned!e *' 


do edlJe=8to poI)'edlJes; 
/* first 
sort vertices 
of eiCh edge by )'-coords *' 


if 
,I(ed.e) 
) ,1<ed •• ) thon 
do; 
x=li 
x=x8(ed'JE!')i 
d(ed.e 
)=, 1<ed•• ); 
lI:1(ed9f)=lI:i 
,'f; 


,=,I<ed") 
: 
,ICed •• )=,1 (ed •• ): 
,Hedge)=y; 
end; 


/* Accu.uli.te ain ind MiX )' Vii ues*, 
if 
JI(Me) 
(ain)' 
then linr=riHedge); 


if 
)'1(edte) ) UK)' then •• xr=yl (edge)i 
'* i dirKtion 
ilill 
is "recondItioned ., 


if 
xl(ed9t»,ICed9.) 


then xri,ht(edw)=true; 
else xrilJht(ectW)=fiilse; 


/. 
ibSOlute annitudes 
Of detti.x JIM delti.Y *' 


del ,Ced.O)=Shl C,1<ed'Je)-JI1(Od •• ),Il: 
if 
lTi,ht(edge) 


thtfl 
delx(t<Ke)=Shl(xI(Odoe) 
- xI(ed9.),Il: 


01"" 
de IX(ed.O)=Sh I(xlCed •• ) - ,!(Od.o),D: 


if del,(edge) 
)= del,(ed'Je) 


then IClredx(edw)=true; 
else IClrechC(ed!@)=filse; 


if 
fIOredx(edge) 


lhon 
r•• (ed •• )=d.I, 
(ed•• )-Shr (del ,(ed •• ), Il; 


else 
r•••(Od•• )=delY(.d.e)-shr 
(del ,(ed.e), 
Il: 


endi 
,* For ill 
the visible 
seJin I ines Of tl'le POtY9on*' 


do Y=liny to MiU; 
do edge=l 
to 
POI yedges; 
/. 
test M/1etherthis 
edge is ietivf 
for the sein 


I ine which is being procesSed*' 
if 
(,B(Od •• )(=,) 
illd 
(,1<ed"»=') 


then .ct ive (edw) =t rue; 
else .ctive(ed,e)=fi.lsei 


end; 


dO ed!Ie~ 
to POIYed!e5i 


if iClivt(Od.e) 
ind 
(,.Ced.elO,) 
Illen 


do; ,* x intercePt cOMPUtition*' 
if 
"(ed 
•• )=,HOd •• ) lhOn 


II:int(ed!e)=x8(edge); 


else 
if .:)r@rdX(ed,e) then 


/* less 
t"'n 
45 d•• r•• 
slop •• 
/ 


doi 
do ..,i If 
reM(ed!@)02768; 


528 
5 


529 
6 
531 6 
531 
6 
532 
7 


533 
7 
53S 
7 
536 
7 
537 6 
538 
5 
539 
4 


if xrilJht{edge) then xint(ed,e)=Xint(edge)tU 
else ,int(edge)=,int(edgel-!; 
rN(edge)=rN(edgehlel 
,(edge); 


end; 
rN(edge)=reo(edge)+del 
,(edge); 


end; 
else 
I. 9TNter 
t~ 
45 
degree 
slOPe 
./ 


dO; 
r"(ed'Ye)=r•• (edge)-del ,(edge); 
if not(reo(ed'Ye)(32768)then 


dO; 


r•• (edge)=rN(edge)+ue1 ,(edge); 
if llrilJhHedge) 
then xlntCedlJe)=xint(edge)+li 


else 'i~t<edge)='int(edgel-!; 


end; 


end; 


endi 


end; 
'* Pick 
UP point NiTS 
in B:ending order 
Of x *, 
/. pul 
iI1dotrl are inde,es into the polnon dau ./ 
'* listptr 
is index used in finding 
dUPlicate pts */ 
ptrH; 
p1r1=1; listptr=ed,el ilit; 


dO Whi Ie 
(P1;rIOed,el 
ilit) 
ifld (ptrlOeclgellMitH 
pul=nextptj 
Px8=llilUC; 


ptrl=nextpt; 
px1:WinXi 
'* be sure there 
iTe U«) vii id Cifldidites *' 


if 
not«ptrl=ed!elilit) 
or (ptrl=edgelil.t» 
then 
Cill 
inkl ine(pxBtpxl,Y)i 


end; 


568 
2 


569 
2 


S7I 
2 


572 2 
574 2 
575 
3 


577 
3 


578 
3 


583 
3 


5114 2 
585 
3 


587 
3 


58ll 
3 


593 
3 


594 
2 


S9S 
3 


597 
3 


598 
3 


613 
3 


684 
2 


Ii nePel y: 
procedure; 
'* dr~ 
edge 
S€'!Nents of POly,on as line segMents *' 
declife e iddressi 


dO e=I to 
PClIJ@rdge5; 


call dda(X\He),YI(e),x!Ce)"lle»; 


eneB 


end I inePOly; 


shONPOI,: 
procedure; 
'* print 
the di~ 
structure 
on the console */ 
declire e ~ress; 
cill 
crtH 
UII 
cstrift.(iiedgetitle,lefl.th(ed.e1:.tte»; 
do e=I to POI1ed.es; 
UII~IJe(e); 


endi 
end Sf'1OWPC)I1i 


fintiSY: 
prOCedure(xs,15); 


/* line dri.,iMl 
exerciser Nith interest in, ~tterns *' 
dec:lire- (xs,ys) ~dress; 
dec:tue (x,y) iddr~s; 
if 
xs)screenwidth-l l~n 
xs=screenlillidth-t; 


if 
ys)screenheitht-l 
then Ys=sneenheitht-U 


dOx-=4 10 screenwicnh-li 


if 
color-.le 
thfn Cill 
setcolor(x ind 8fh); 
Cit I ddi()(5,YS,X,Screenheitht-l); 
if 
cits 
then do; cill 
coCCi); return: end; 


encH 
do 1=1to screenhfi9ht-t; 
if 
colormde then CIIJI 5e'tcolor(y ind 11h); 


Cill 
ddi(XS,15,screen.icnh-l,screenhei9ht-Y-l)i 


if 
csts t~n 
dO; nil 
coCCi); returni endi 


end; 
do x=I to scrernwidttrl; 
if 
color.ade then Cill 
setcolor(x ind 81h); 
cill 
ddi(J(5,Y5,5creenNidttrx-l, e); 
if 
C!its then dOi cill 
co(cil; 
return; end; 


encH 
do J=I to screenhei9ht-t; 


6lII5 
3 
687 
3 
6lIl8 
3 
613 
3 
614 
2 


629 
3 
631 3 
631 
3 


632 
3 
633 
4 


634 
4 
635 
4 
636 
3 
S38 
3 
639 
3 


6411 
2 
642 
2 


643 
2 


646 
2 


647 
2 


649 
2 
65ll 
2 
651 
3 
6S2 
3 
6S3 
3 
6S4 
3 
6S5 
3 
656· 
3 
658 
3 
Ii6lI 
3 
662 
3 
664 
3 
Ii66 
3 
667 
3 
668 
4 
669 
4 
671 4 
671 
3 


6n 
3 


if colorlOde then call setcolor(, 
and Ifh); 


eill 
ddi(xs,1!i,',Y); 
i1 c5ts then dO; cill 
coCCi); return; end; 


eT~n 
end fintl51; 


cleuscreen: 
prOCedure(villi 
declue Vi' 
iddressi 
/. Uke idViIIlUgeof the lllIl6 str in! o••><itions ./ 
call seto(val.inl.ltIl'Jth(F!lI»; 
call seto(val,ifBloitIl'Jth(FB()); 


end clNrscreen; 
turtle: 
C1rocfl:kIre; 
,. 
the turtle 
is i si.le 
lJT~hic inPUt deVice 
•• 
/ 
/. turtle 
ShOOSitself 
as a rectaMle 
on the CRT•• 
/ 


/. the .ser iii>'like the turtle 
craol ./ 


/. 
UP, dO_h r i9ht, ind 
Ieft. 
*/ 
/. 
the 
cr.1 
5Peed 01 the turtle 
is i!d.iustible. */ 


,. 
USiM 
cur""t 
llOSition of turtle, 
severil 
c~dS 
*' 


/. 
lIlY lie invokedWhichcontribUte verlic@s to./ 


,. 
POlnofi dill. structure for 
liter 
Plottin,. *' 


,. 
wrttx 
Ca.inds ire: sUTtPOIY90n,addverteK, *1 


/. 
newedlJeSet, 
ind 
@ndPOIY~on. *' 
deelire chir byte; 
declire 
(x, Y,delti) 
iddress; 
declire 
(OldlllOde,OldfOnt,inking) byte; 


l09lJleturtle: 
procedure(x,y); 


,. 
Since the plO1l1Odehis 
been set to 2 *' 


,. 
this 
procedurecl»Pletlents rectangular turtle 
*1 


decliTe 
(X,Y) iddr@5S; 
Cill 
Plotrect(x-2, Y-2, x+2,)'+2); 


end 1099letur1lei 


eriNlto: 
pnXedure(xnew,ynew); 
'* criNt to I\ftil coordinite trOll present position. 
*/ 
'* 1irst erase line se9MeT'ltto 
IllSt entered vertex */ 


/. 
then driM I ine to newturtle 
~ition 
MId *, 


/. add the turt Ie•• / 
decliTe 
hcnew.Yn8l) 
iddrfSsi 
Cill 
to9tleturt 
le<X,y); 
if 
inkiM then 


dO; 
Cill 
ddi(xl(POIYed9es),r8(POI1edCJeS) 
, XI Y)i 


cill 
ddi(xl(POIYed9es),yl(POIndlJeS), mew. yneN); 


end; 


X=XIl8; 
FYnewi 
Cill 
t09!leturtle(x,y); 
enclcriWlto; 


oIdtmde=pIotMode;oldfont=p1ot1ont; 
int<in!=Ulse; 
Plo~2; 
PlotfOflt~i 
delti=4i 


ctoor=l; 
x=screenNidthl2i 
r=screenheilJhtl2i 
/* initiit 
turtle 
position ., 
Cill 
tonleturtle(x, 
y)j 
do Nhile (chir()'E'); 
Cill 
erlfi 


eill 
cstr in9(atun; IeQra.P\, len9th(turt IePrOMPt); 


chir=ci; 
cill 
CO(Chir)i 
Chir=UPciW(Chir); 


if 
Chir='C' then delti=NOrdin; '* set craMt sPeed*' 
if 
chir='U' 
then cill 
criWtto(x,Y-delti); 
/* UP*' 


if 
ehir='D' .then cill 
criWlto(x,Y+deIU); 
/* dONTI*/ 
it 
Chilr='L' then cill 
CriNlto(X-delti, 
Y); 1* left *' 


if 
ChAr='R'then cill 
cralto<x+deltl,Y); 
'* right.' 


if chir=' S' then /. SUrt 
001"'on *1 


dO; 
cill 
stirtPOI1(1(, y); 
inkift~rue; 
eod; 


if 
Chir='A' then ,* ~ 
vertex to current edte5et *1 


dO; 


m • 
m 
.. 


675 
3 
676 
3 
m • 
67ll 
4 


67'J 
li8I 
681 


682 


683 
684 
68S 
686 


6lIll 
Ii89 
698 
692 


693 


694 
695 
698 
699 
7llI 
1Il1 
1Il2 
1Il3 
1Ill 
1Il5 
1Il6 
Ml 
1IlIl 
7I1'J 


711 


711 
712 


715 
716 
717 
718 


719 
721 
721 
722 


723 
724 
72S 
72fi 


7'Zl 
72B 
729 
T.lI 
731 
732 
733 
734 


73S 
736 
737 


eill ~vertex(xI1); 
end; 


if chir:'£' 
then '* eId IIOlrJOfl and !Kit 
turtle 
./ 


dO; 
(ill 
endPOIY; 
coil 
ddo(d!(OOI>O<l.05),ri!(POIYed"",). 
xl (001>0<1.05),,l(POIYedoos»; 


endi 
if Chir::' Pf then /* bf9 in new eodlJe5et *1 
do;'* idd Iine to close off li5t 
ed,eset 
-/ 
coli 
ddO(d!(OOIJed.05),rlHPOIYed"",). 
xS(thisedlJeset), 
)'@(thisedge5et»i 
'* erz;e the turtles 'itest 
line se9lnent ./ 


ell 11 ddi(X, y,xl(POI 
Yedge5), 
yi1(POIYed9E!'S»; 
e.tll newdIJeset(x,y)j 
end; 
if Chir='H' 
then eill 
cstrin,GhuTtleohPlp, 
lenlJth(turtlehelp»; 


eneB 
eill 
t09CJleturtle(x,y)j 
PlotlltOcle=oldMOdei plotfont=Oldfonti 
end tuTtle; 
/* Heore.re three silple 
IIOI"On5to d€'fllOllstrate 
hc.. fiKPd s~.es 
light 
be PT09riHed *1 


selupl: 
procedUre; 
'* ~ engineerinlJ 
SYIlbOI *' 
dee-Iue 5 ~re5s; 
if 
color~e 
then 5=1; else s=2i 


eill 
sUrtPOI y(25*5,~); 


(i.11 ~vertex(~, 
25ts) i 
eill ~rteX(5I*5,.5); 
coil 
idd""rtexUilIIO'5,4IOs); 


coil 
iddvertex(lilllO'5,2S0s); 
cill 
idd •• rtexU2S0s,SlI*s); 
(ill 
iddvertexO..-s, 15*5); 
cill 
iddvertexUilIIO'5,680s); 


(ill 
iddvor\@x(Sl!*s.680s); 
cilli 
iddvertex(~, 
7S*5); 
cill 
fndPOly; 


end setlfPl; 


setup2: procedUre; 


/* ThOn._bOrs 8 in<! 6 Ir •• lIBi 
*/ 
deelilre 5 id:fress; 
if color.:>dethen 5=1; else s=2i 
/* ThOoutside 
ed•• of thO 8 */ 


coil 
stortOOIJ(Sl!*s.l 
••• 
); 


cill 
iddvertex(~,2IBt'5) 
i 


(ill 
iddvertex(IB1t:s,2M*!i)i 


cill 
iddvertexOl8*s, 111*5)i 
/* Ono ""10 
In tho 
8 */ 


coil 
n-.l 
•••• t(680s,l19*s); 
Cill 
iddvertex(~, 
1~); 
cill 
~dverte)( (w.s, 145*5); 
coil 
iddvor\@x(9l!Os, llllos); 


/* A socond ""I. 
In tho 8 0/ 
cill 
n-.l 
•••• t(680s.155*s); 
coil 
iddvertex(9l!Os.ISSOs); 


Cill 
iddvertex(w.s, 1~) 
; 


(ill 
iddVOrtex(680s.19l!Os); 
/* Tho out I I•• of thO 6 */ 
Coil •••••••••••• t<l2S0s.1 ••• 
); 
coil 
iddVertex<l7S0s, 1••• 
); 
Cill 
idd •• rtex(l7S0s.11 •• s); 


coil 
iddvor\@x<l3S0s, l1•• s); 


coil 
iddVertex(l3S0s.14S0s); 


COil iddv.r\@x(l750s.1450s); 
Cill I iddvertex(17'5*5,218*5)i 
Cilil iddvertexCl25*s,28lI*s)i 
I. 
The hOle in the 6 *1 
(ill 
n••••d•••• t<l3S"s, ISS•• ); 


cill 
iddvertexCl65*s.155*5); 


Cill 
iddvertexCl65*s,191*s); 


738 
739 
7411 
741 


742 
743 
746 
747 
748 
749 
7Sll 
751 
752 
7S3 


754 


75:i 
2 
756 
2 
7'57 
3 
7S8 
3 
759 
3 
768 
2 
761 
3 
762 
3 
763 
3 
764 
2 


765 
766 
767 
768 
769 
771 


771 
772 
773 


774 
m 
776 
2 


m 
2 
778 
2 
779 
2 
781 
2 
783 
2 
785 
2 
787 
2 
789 
2 
791 
2 
793 
2 
79S 
2 
7'I1 
2 
799 
2 
881 
2 
llll3 
2 
8llS 
llll7 
llll9 
811 
813 
815 
817 
818 


819 
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(ill 
iddvor\@x(l3S0s,1911Os); 
cill 
fndpolyi 
end setuP2i 
setuP3: procedure; 
1* A tYPical Palnon *1 
deelire 5 iddressi 
if colorlOde thfn 5=1i else s=2i 
COil sti,tool 
,USl!*s, Sl!*s); 
call 
iddvertex(2iJtt:s,7S*s); 


'ill 
iddvertex(22'5*s,151*s); 
coil 
iddvor\@xCI5llOs.1SOs); 


coil 
iddvor\@xCI2SOs,Sl!*s); 


coil 
iddVor\@x(2\lIOs,2S0s); 
Cill 
fndPOIri 
end setuP3; 


setUP4:procedUre; 
1* • color trst 
*1 


deelire (K,y) iddrP55; 
do ,=t to 7; 
'ill I setcolor(y); 
WI 
plot,o<t(B. 
,038. 239, (,+l)03&-1l; 


end; 
do x=I to 7; 
call setcolor(K); 
coil 
Plotrect(x*38.B, 
(x+l)'3ll-1,Zl'3); 
endi 
end setllP4; 
'* the uin 
pr04Jrill loop*' 
'* after ,lsriM 
the Hille 
buffer ., 
'* ifld esUbli51't1nIJthe initi.illOdes *' 
'* it si~lr 
tests the console input CMrilCters*' 
'* fOr i vnietr 
of user selected Cc.indS *' 
'* At ·either !'Iiin or Turtle COMMiI\d 
level *' 
'* UserMilYtnlif the chiracter 
-1'1- 
for help*' 


call setWkfe(2); 
WI 
•• ttont(Bl: 
Cill 
setcolor(8fh)i 
'* red, IJrt?en,blue, ind xtra Yields White*' 
eilll 
cOlorcrt(true) i 
call 
crlf; 


PO I YedlJeos=8; 


dOIIIhi Ie truei 
,. do fOrever*' 


c,all cstriftlJ(CMiinPr(St,len9th(8iinprC*lt»; 


Chir=Ci; 
e,all cO(Chir) i 
Chir=UPCise(Chir)i 
if 
(Chir='"') 
then eill 
setMode(wordin); 


if 
(c~r='B') 
then Cill 
setcolor(-ardin); 
if 
(Chir='Q') then Ci'l 
cOlorcrt(not eOlorMOde); 


if 
(chir='!') 
then (ill 
setfont(wordin)i 


if 
(chir='S') 
then cill 
stirtPOlrhmrdin,lIOrdin)i 


if (chir='A') 
then (ill 
,addverteK(l«lrdin,l1Ordin); 


if 
(Chir='[') 
thttn Cill 
endPOly; 
if 
(Chir='N') thttn cill 
newdge5et(wordin,wordin)i 


if 
(Chir='P') then Cill 
fillPOly; 
if 
(Chir='C') then Cill 
FINrscreen(_h); 


if 
(chir='P) 
then Cill 
fintiSy(wordin,NOrdln)i 
if 
(Chir='H') then eill 
estriM(iuinheIPlleTIIJth(~lnheIP»; 


if 
(chir='l') 
then Cill 
linePQly; 


if 
(Chilr='T') then C~dlturtlei 
if 
(Chir=' 1') then (ill 
setupli 


if 
(chir=' 2') then cill 
setup2; 
if 
(chir=' 3') then Cill 
setuP3; 
if 
(Chir='4') then Cill 
setuP4; 


if 
(chir='1') 
then Cill 
S!"lONPOly; 
Cill crlH 
end; 
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8II67D 
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iNA 950-1 
LOCAL AREA NETWORK SOFTWARE 


• 
Provides Reliable "Virtual Circuit" 
Process-to-Process Message Delivery 
Service 


• 
Pre-standard ISO OSI Transport Control 
Layer Services: 
-Guaranteed 
Message Integrity 


-Data 
Rate Matching (Flow Control) 


-Multiple 
Connection Capability 


(Process Multiplexing) 
-Variable-Length 
Message Support 


• Seven Transport Commands Are 


Available to Client S/W 


• iNA Services Are Operating System 


Independent via MIP in Multibus 
Applications 


• 
Provides Comprehensive Network 
Management Functions to Enable 
Maintenance and Efficient Operation 


• 
Pre-standard ISO OSI Network 
Management Services: 
-Collection 
of Network Usage 
Statistics 
-Transport 
and Data Link Parameter 


Inspection and Setting Capability 


-Fault 
Detection and Isolation 
-Initialization 
Support 


• Seven Network Management 
Commands Available to Client S/W 


• 
iNA Implemented on Intel's iSBC® 550 
Ethernet* Controller Board Set 


iNA 950-1 is a RAM-based software which provides a high-level reliable message transport 
service plus exten- 
sive network 
management 
functions 
to help maintain 
and efficiently 
operate a local area network. 


'iNA is implemented 
on Intel's iSBC 550 Ethernet Communications 
Controller 
Board set and when connected 
to 
an Ethernet (Version 1.0, Sept. '80) transceiver 
or equivalent 
(like INTELLlNK™), it forms a complete 
Ethernet 
local area network 
communications 
subsystem 
for Multibus®-based 
network system applications. 
iNA 950-1 
together 
with the iSBC 550 implements 
the physical and data link layers (Ethernet) and the transport 
("class 4") 
layer functions 
of the ISO OSI Model. 


iNA 950-1 is the first software product in Intel's family of LAN building 
blocks. In addition, 
it is the first product 
toward fully implementing 
a family of ISO OSI standard S/W products. 


•Ethernet is a trademark of Xerox Corporation. 
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iNA 950-1 is a RAM-based 
software 
which provides 


reliable 
process-to-process 
communication 
for im- 


plementation 
on Intel's iSSC 550 Ethernet Communi- 


cations 
Controller 
board 
set 
in Multibus-based 


applications. 


The iNA 950-1 design is a pre-standard 
implementa- 


tion of the Transport 
"class 4" Control 
Layer of the 


ISO OSI model. The Transport 
Control 
Layer (TCL) 
ensures a reliable, full-duplex-message 
delivery 
ser- 
vice on top of the "best effort" 
Ethernet 
packet ser- 


vice 
provided 
by the 
iSSC 550 physical/data 
link 


functions. 


The iNA 950-1 design also includes 
a Network Man- 


agement 
function 
(NM), which 
provides 
services to 


help support 
and effectively 
maintain 
the operation 


of the network. It is the residence of tools and offline 
utilities 
which perform 
such services as booting 
up 


new nodes; 
performing 
error 
recognition 
and log- 


ging to aid in problem 
isolation 
and resolution; 
and 


supporting 
network 
planning 
by maintaining 
statis- 


tics on network 
loading 
and utilization. 


The client 
OS (RMX-86, RMX-88, and others) 
can 


easily interface 
to iNA via MMX 800 (MIP). 


TCL (TRANSPORT CONTROL LAYER) 
FUNCTIONAL DESCRIPTION 


iNA 950-1 is an implementation 
of the Intel Network 


Architecture, 
which 
follows 
the ISO Open Systems 


Interconnect 
reference 
model. 
Figure 
1 shows the 


position 
of TCL in the OSI model. 


iNA's TCL provides 
a reliable 
message delivery 
ser- 


vice via virtual 
circuits 
between 
processes 
(client 


software) 
running 
on 
computers 
("hosts" 
or 


"nodes") 
anywhere 
in an Intel Network Architecture 


(iNA) compatible 
network. 


TCL Services 


RELIABLE 
DELIVERY 


Data is delivered to the destination 
in the exact order 


it was sent by the source, with no errors, duplicates 
or losses, regardless 
of the quality 
of service avail- 
able from the underlying 
packet delivery 
service. 


DATA RATE MATCHING 
(flow control) 


TCL attempts 
to maximize 
throughput 
while 
con- 


serving 
communication 
subsystem 
resources 
by 


controlling 
the 
rate at which 
messages 
are sent 


based on its own resources 
and the availability 
of 


receive buffers 
at the destination. 


PROCESS 
MULTIPLEXING 
Several processes can simultaneously 
use TCL with 


no risk of interference 
with others. 


VARIABLE-LENGTH 
MESSAGES 


The client 
software 
can submit 
arbitrarily 
short 
or 


long messages for transmittal 
without 
regard for the 


minimum 
or maximum 
packet lengths supported 
by 


the underlying 
packet delivery 
service. 


TCL provides 
these services, 
with a connection 
(or 


virtual 
circuit) 
service: 
Pairs of clients 
create, send 


data 
over, 
and 
terminate 
connections 
between 


themselves. 


Client processes are identified 
by means of sockets. 


A socket consists of a Network 
ID, a Host ID, and a 


Port. It is the network-wide 
address of a process (or 


related group of processes) running 
on a host in the 


network. 


The Port specifies the process within a host, the Host 
ID specifies which physical node in the network, 
and 


the Network 
ID specifies 
a portion 
of a large inter- 


networked 
system. Host IDs are unique over all hosts 


ever installed over time, so net IDs are actually redun- 
dant 
information 
that 
provides 
additional 
routing 
information 
to the 
Network 
(routing) 
layer, when 


present. 


TCL is capable 
of supporting 
up to twelve 
virtual 


circuits simultaneously. 
One is dedicated to Network 


Management, 
making eleven available to the user. 


TCL (implemented 
on iSSC 550) can support 
in ex- 


cess of 70K bytes/sec throughput. 
This performance 


would 
be available to one virtual 
circuit 
or would 
be 


apportioned 
to the number of virtual circuits 
in oper- 


ation; 
i.e., throughput 
would 
be less per virtual 
cir- 


cuit depending 
upon utilization 
by the others. 


The following 
command 
services 
are supported 
by 


TCL: 


OPEN 
The OPEN service attempts to establish a connection 
(virtual circuit) with a specified, 
partially specified, or 


unspecified 
socket on the network. 
It returns a CON- 


NECTION ID which is used by the client to refer to this 
virtual 
circuit 
in other TCL service requests. 


inter 


SEND 
The SEND service queues the client's transmit buffer 
on the virtual circuit 
specified 
by the CONNECTION 


10. The messages will be transmitted 
in the order 


they are queued on each virtual circuit. The transmit 
buffer can consist of noncontiguous 
areas of mem- 


ory blocks. 


POST RECEIVER 
BUFFER 


Clients 
use POST RECEIVER 
BUFFER service 
to 


supply the empty buffer 
to TCl 
to place messages 


sent to this socket. 
The TCl 
queues 
the receiver 


buffer 
on the virtual 
circuit 
specified 
by the CON- 


NECTION 
10. The 
receiver 
buffers 
may 
be 


noncontiguous. 


STATUS 
The 
STATUS 
service 
places 
the 
connection- 
independent 
information 
(such 
as ... 
number 


of virtual 
circuits 
established), 
and the connection- 


dependent 
information 
(such 
as ... 
number 
of 


packets transmitted 
to a particular CONNECTION 10) 


into the client specified 
buffer. 


DEFERRED 
STATUS 
DEFERRED STATUS instructs TCl to notify the client 
when the connection 
enters 
the established 
state. 


This service provides the client with the recognition 
of connection 
establishment 
without 
using succes- 


sive interrogation 
of the connection 
state via the 


STATUS request. 


CLOSE 
A CLOSE request initiates 
the graceful 
termination 


of the virtual 
circuit 
specified 
by the CONNECTION 


10. TCl will complete the transmission 
of this virtual 


circuit's 
previously 
queued 
local 
transmit 
buffer 


before closing. 


ABORT 
The ABORT service immediately 
terminates 
the vir- 
tual 
circuit 
specified 
by the 
CONNECTION 
10, 
releases the CONNECTION 10, and returns any other 
locally outstanding 
request blocks. 


NM (NETWORK MANAGEMENT) 
FUNCTIONAL DESCRIPTION 


Network 
Management 
provides 
functions 
to aid in 


the planning, operation, 
and maintenance 
of a multi- 


station 
network. 
Planning 
functions 
include 
collec- 
tion of network usage statistics; 
operation functions 


include parameter inspection 
and setting capability; 
and maintenance 
functions 
include 
access to layer 


statistics 
and loopback 
tests. 


Network Management-Accessible 
Objects 


Each layer allows Network 
Management 
access to 


selected 
parts 
of 
its 
internal 
data 
base 
(i.e., 


"objects"). 
Normally 
objects 
are read-only 
quanti- 


ties. There are two special types of objects: 
parame- 


ters and counters, 
which 
may be modified 
by the 


users. 


• 
Parameters 
are values 
which 
adjust 
the 
opera- 


tional 
characteristics 
of a layer. They may be ad- 


justed by using the SET operation. 


• Counters 
record the number of times some event 


occurs. They may be read, or read/then 
cleared. 


COLLECTION 
OF NETWORK 
USAGE STATISTICS 


Thirty-six 
individual 
network 
values 
("objects"), 


twenty-five from transport 
layer and eleven from data 


link layer (implemented 
by iSBC 550), are accessible 


to the client software 
via the Network 
Management 


functions. 
Within 
the TCl, 
fourteen 
connection- 


independent 
objects 
(i.e., number of virtual 
circuits 


open) 
are 
available 
and 
eleven 
connection- 


dependent 
objects (i.e., number of packets sent for a 


particular 
connection 
10) are also available. 


Examples 
of objects 
available 
from 
data link layer 


are: number of collisions 
at a node, or the number of 


packets discarded 
due to CRC errors. This informa- 


tion may be obtained 
locally, or remotely from other 


nodes, making possible 
network 
management 
from 


a single dedicated 
node. 


Additionally, 
maintenance 
services 
are provided 
by 


Network 
Management's 
capability 
of performing 


loopback tests to any other node on the network. For 
example, packets can be echoed off of other nodes 
which 
essentially 
tests 
that 
node's 
receiving 
and 


transmi~ting 
functions. 


PARAMETER 
INSPECTION 
AND 
SETTING 
CAPABILITY 
Network 
Management 
enables the client to inspect 


such TCl parameters as timeouts and make changes 
to help improve 
node efficiency 
based on network 


usage statistics. 


INITIALIZATION 
SUPPORT 
Network 
Management 
assists 
in initializing 
and 


booting 
up nodes both locally and remotely ("down- 


line loading"). 


intel' 


iNA Network 
Management, 
coupled 
with 
data link 


diagnostics 
resident 
in the iSBC 550, form a com- 


prehensive 
network 
maintenance 
and 
planning 


resource 
critical 
to the success of networked 
sys- 
tems in end-user environments. 


The following 
seven command 
services 
are sup- 


ported 
by NM: 


READ 
Returns 
the value of the specified 
objects 
to the 
client. 


READC 
Reads and if any of the objects are counters, they are 
cleared to zero. 


SET 
Assigns a new value to the specified 
objects. 


CAUSE EVENT 
Allows users to add connection 
data base memory to 


the Transport Control 
Layer. 


READ MEMORY AND SET MEMORY 
This interface 
is provided 
as a debugging 
feature. It 


can be used to read or set the counters of any part of 
memory as seen by the iSBC 550, local or remote. 


The following 
two interfaces 
support 
the bootstrap 


server to directly 
access the Data Link: 


SUPPLY BUF 
This service 
is used to provide 
NM with 
buffers 
in 


which to place received packets. 


TAKE BACK 
Causes NM to return 
all the receiver buffer 
to the 


client. 


iSBC 550 IMPLEMENTATION/INTERFACE 
DETAilS 


iNA 950-1 is implemented 
as RAM-based software on 


the processor 
board of the iSBC 550 Communica- 


tions Controller 
board set. iNA 950-1 and the iSBC 


550 firmware 
operate 
under 
control 
of a resident 


realtime 
executive 
running 
on the 8088 CPU. The 


firmware 
consists 
of the 
Multibus 
Interprocessor 


Protocol 
(MIP), those ,data link function~ 
not sup- 


ported by hardware, a bootstrap 
loader, and diagnos- 


tics. Together they provide the Transport, Data Link 
and the 
Physical 
Link 
functions 
of the 
ISO OSI 


model, in addition to the Network Management func- 
tion. (See Fig. 2.) 


The 
iNA-iSBC 
550 communications 
subsystem 
is 


controlled 
from the Multibus 
host CPU via the Multi- 


bus Interprocessor 
Protocol 
(MIP). 
Upon 
system 


start-up 
or reset, the client 
software 
initiates 
the 


loading of iNA 950-1 object-code 
into the iSBC 550 


RAM. This is performed 
by the bootstrap 
loader resi- 


dent in the firmware. 
The loading 
can be either 
lo- 


cally from the host or remotely via the network 
and 


the code may be located either 
locally or remotely. 


iNA 950-1 requires approximately 
15K bytes of RAM 


memory. 


In order to issue a request to the communications 
processor, the host generates 
a request-block 
and 


uses the iMMX 800 Transfer Message 
Interface 
to 


send the request-block 
to the MIP socket on the iSSC 


550. iMMX 
800 is an implementation 
of MIP for 


iRMX™ 80, 86, and 88. The request-block 
consists of 


specifying 
the command (OPEN, SEND, etc.) and the 


values of the parameters 
required. TGUNM 
perform 


their functions 
on top of the services provided by the 


data/physical 
link functions 
of the iSSG 550 hard- 


ware. 
Upon 
completion 
of the 
requested 
service, 


TGUNM 
return 
the 
request-block, 
containing 
the 
response, to the host via MIP 


Part Number 
iNA 950-1 


Description 
• 
Seven Intellec®-compatible 
diskettes (written 
in PUM 


assembly language) containing 
-Source 
code and listings 
-Object 
code 
-Sou 
rce-to-object 
generation 
tools 


-Application 
examples 


• 
Programmer's 
Reference 


Manual 


• 
Architecture 
Reference 


Manual 


ISB~ 
IlOl:30 
IIRMX eo- 
lMII12A 
lMII25 
lMII40 


iSBC 550 
CONTROLLER PROCESSOR 
BOARD 


CLIENT 
APPLICATION 
SOFTWARE 


HOST OS 
IRMX" 
80, IRMX 88 
OR IRMX86 


BOOTSTRAP 
LOADER 
AND 
DIAGNOSTICS 


UNDER 
RESIDENT 
OS 


inter 


iDCM 911·1 INTELLlNK™ 
ETHERNET* 
CLUSTER MODULE 


• 
Eliminates 
need for transceivers 
and 
Ethernet 
coaxial 
cable for a local 


cluster 
of workstations 


• 
Permits 
clustering 
of up to nine 


workstations 
In a smaller 
area 


• 
Enables 
local cluster 
of nine 


workstations 
to connect 
to main 


Ethernet 
cable with only one 


transceiver 


• 
Enables 
workstations 
to be up to 100M 


from main Ethernet* 
cable 


• 
Complies 
with the Ethernet 


Specification, 
Version 
1.0, September 


1980 


The Intel/ink™ 
Ethernet 
Cluster 
Module 
is a device 
used as a means of interconnecting 
up to nine Ethernet 
devices without 
the need for Ethernet 
coaxial 
cable and transceivers. 
The Intel/ink 
module forms a standalone 
Ethernet 
local 
area 
network 
with 
"interconnection" 
communication 
capability. 
The 
Intel/ink 
module 
(and 


attached 
devices) 
can optional/y 
be connected 
to the Ethernet 
coaxial 
cable through 
a single 
transceiver . 
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iDCM 911-1 INTELLlNK™ 


ETHERNET* CLUSTER MODULE 


Intellink 
module 
performs 
the same functions 
as a 
standard 
Ethernet transceiver. It buffers receive and 


transmit 
data, 
detects 
attempts 
by two 
or more 


stations 
to gain access to the line simultaneously, 


. signals the presence of a collision to the transmitting 
stations, and transmits 
the jam signal prior to initia- 


tion of the random 
back-off 
algorithm. 
It complies 


with 
all of the 
interface 
parameters 
set forth 
in 


"The 
Ethernet 
Specification," 
1.0 Version, Septem- 


ber 1980. 


Ethernet Work Station to Intellink™ 
Interface 
(WI) Connectors 


There are nine WI interface 
connectors 
into which 


Ethernet-based 
systems 
can 
be connected. 
Ea'ch 


connector 
has the same signal 
pairs 
as does the 


equivalent 
connector 
on 
a standard 
Ethernet 


transceiver. 


Intellink™ Module to Transceiver 
Interface 


(IT) Connector 


The IT interface 
connector 
on the Intellink module is 


used to connect the local cluster to the "main" 
Ether- 


net cable through 
a standard 
transceiver, or can be 


left unconnected 
for standalone operation. The char- 


acteristics 
of this connector 
are identical to an Ether- 


net system to transceiver 
cable connector. 


The Intellink 
module 
can function 
in standalone 


operation 
in which case it appears as a "zero length 


Ethernet 
segment" 
for 
up to nine 
Ethernet-based 


systems, 
or optionally 
can 
be connected 
to the 
"main" 
Ethernet 
coaxial 
cable 
through 
a single 


transceiver. When connected 
to the "main" 
Ethernet 


coaxial 
cable, it extends the Ethernet 
system inter- 
face to the transceiver 
from 50 meters to 100 meters. 


(Figure 1). 


Physical Characteristics 


Width 
14 in. (35.56 cm) 


Height 
7.8 in. (19.81 cm) 


Depth 
5.5 in. (13.97 cm) 


Weight 
10 lb. (4.52 kg) 


ELECTRICAL CHARACTERISTICS 


Input Voltage Range: 
(Voltages 
AC RMS) 


Voltage 
(15%) 


100V ±15% 


120V ±15% 


220V ±15% 


240V ±15% 


Temperature: 
10° to 40°C Operating 
-40° to 70°C Non-Operating 


Humidity: 
10% to 85% Operating 
5% to 95% Non-Operating 


Part Number 
Description 


iDCM 911-1 
Intellink, Ethernet cluster module, 
Version 1.0 


iSBC®S89 
INTELLIGENT 
DMA CONTROLLER 


• Configurable 
as either an intelligent 


slave or MULTIBUS® master 


• 5 MHz 8089 I/O Processor 


• MULTICHANNEL 
DMA I/O bus inter- 


face with Supervisor, 
Controller 
or 


Basic Talker/Listener 
capabilities 


• Two 8/16-bit iSBX™ bus connectors 


• DMA transfer 
rates up to 1.25 


megabytes 
per second 


• User Command 
Interface 
Firmware 


Package provides 
high level I/O 


commands 


• 8K bytes of high-speed 
dual-ported 


static 
read/write 
memory 


• Sockets 
for up to 32K bytes of read 


only memory or additional 
byte-wide 


static 
RAMs 


• Three programmable 
timers 


The iSBC 589 Intelligent 
DMA Controller 
is a member of Intel's complete 
line of MULTIBUS 
microcomputer 
systems 
which take full advantage 
of VLSI technology 
to provide 
economical 
computer 
based solutions 
for OEM applica- 
tions. The iSBC 589 board is a general purpose, 
programmable, 
high-speed 
DMA controller 
on a single 6.75 x 12.00 
inch printed circuit board. Using the board's 
dual-port 
RAM and standard 
EPROM resident firmware, 
the on-board 


Intel 8089 1/0 Processor 
can perform 
memory to memory block transfers 
and complex 
1/0 operations 
via two iSBX 
connectors 
and the MULTICHANNEL 
1/0 bus at DMA transfer 
rates up to 1.25 megabytes 
per second. 
Acting as 
an intelligent 
slave to one or more iSBC 86, iSBC 88 or iSBC 80 single board computers, the iSBC 589 board enhances 
the system's 
overall performance 
by relieving 
the host CPU of time consuming 
1/0 operations. 
The board's 
unique 
combination 
of performance, 
on-board 
intelligence 
and flexible 
hardware 
1/0 interfaces 
make the iSBC 589 board 
the ideal solution for applications 
with specialized 
1/0 requirements, 
such as high-speed 
data acquisition, 
graphics, 
instrument 
automation 
and specialized 
peripheral control, that previously would have necessitated 
an expensive cus- 
tom designed 
1/0 controller. 


The following 
are trademarks 
of Intel 
Corporation 
and may be used only 
10 describe 
Inlel 
products: 
Intel, 
CREDIT, 
Index, 
Insile, 
Intellec, 
Library 
Manager, 
Megachassis, 


Micromap. 
MULTI BUS, PROMPT, 
UPI, ,..Scope, 
Prom ware, 
MeS. 
ICE, iRMX. 
iSSC, 
iSaX, 
MULTIMODULE 
and ies. 
Intel 
Corporation 
assumes 
no responsibility 
for the use of any 
circuitry 
other 
than Circuitry 
embodied 
in an Intel product. 
No other circuit 
patent 
licenses 
are implied. 


Two Modes of Operation 


The 
iSBC 
589 Intelligent 
DMA 
Controller 
is ca- 
pable of operating 
either 
as a stand-alone, 
high- 


speed data acquisition 
controller 
or as an intelli- 


gent slave. In stand-alone 
mode, external 
requests 


cause the Intel 8089 110 Processor 
to execute 
110 


programs 
contained 
in its on-board memory. As an 


intelligent 
slave to one or more Intel single 
board 


computers, 
the 
lOP 
can 
perform 
sophisticated 


DMA operations 
in response 
to high 
level com- 


mands issued by the host processor. 
While operat- 


ing in either mode, the iSBC 589 board may act as a 
MULTIBUS 
master to access 
any system 
memory 


or 110 resources. 


Input/Output 
Processor 


The iSBC 589 board contains 
a 5 MHz Intel 8089 


HMOS 
110 Processor, 
whose 
architecture 
and in- 


struction 
set have been optimized 
for performing 


DMA operations. 
The DMA function 
of the 8089 


lOP uses a two cycle approach 
where the informa- 
tion actually 
flows 
through 
the 8089 lOP. This ap- 


proach 
to DMA vastly 
simplifies 
the bus timings 


and enhances 
compatibility 
with memory 
and pe- 


ripherals, 
in addition 
to allowing 
operations 
to be 


performed 
on the data as it is transferred. 
Opera- 


tions 
can 
include 
such 
constructs 
as translate, 


where 
the 8089 automatically 
vectors 
through 
a 


lookup table and mask compare, 
both on the "fly". 


This DMA capability 
includes 
flexible 
termination 


conditions 
(such as external 
terminate, 
mask com- 


pare, single 
transfer 
and byte count 
expired). 


The 8089 lOP supports 
two logically 
and physically 


separate 
110 channels. 
The lOP maintains 
separate 


register 
sets for each 110 channel which allows 
the 


processor 
to alternate 
operation 
between 
the two 


channels 
without 
incurring 
context 
switching 


overhead 
delays. 


DMA Capabilities 


The iSBC 589 board supports 
both individual 
byte 


or word data transfers and DMA block transfer oper- 
ations 
among 
its MULTICHANNEL 
interface, 
two 


iSBX connectors, 
on-board RAM and the MULTI BUS 
interface. 
Each of these devices 
may be combined 


MULTIBUS' 


INTELLIGENT 
SLAVEIMUL 
T1MASTER 
INTERFACE 


with any other as the source and destination 
for a 
DMA operation. 
The same firmware 
commands 
are 
used for all of the 
DMA source 
and destination 
combinations. 


MULTICHANNEL 
Capabilities 


The MULTICHANNEL 
bus provides 
a high-speed 
8-bit or 16-bit wide data path for block data trans- 
fers 
between 
external 
devices, 
such 
as 
instru- 


ments, 
peripherals 
and other computers, 
and the 
iSBC 589 board. The iSBC 589 board can access up 
to 15 other devices on the MULTICHANNEL 
bus at 
distances 
of up to 15 meters and has the ability 
to 
address 
up to 
16 megabytes 
of memory 
and 16 


megabytes 
of I/O on each device. 


The iSBC 589 Intelligent 
DMA Controller 
can inter- 


face to the MULTICHANNEL 
bus in one of three 


modes: 
as a Basic 
Talker/Listener, 
a Controller, 


and a Supervisor. 
In Basic Talker/Listener 
Mode, 


the iSBC 589 board monitors 
the MULTICHANNEL 


for requests 
from 
a Controller 
or the bus Super- 


visor to perform 
a read or a write operation, 
but it 


has 
no 
bus 
control 
capabilities. 
In Controller 


Mode, the board can request temporary 
control 
of 


the MULTICHANNEL 
bus from the bus Supervisor 
and thus 
initiate 
data transfer 
operations. 
In its 


MULTICHANNEL 
Supervisor 
configuration, 
the 


iSBC 
589 
has 
the 
capability 
to 
initiate 
data 


transfers 
on the bus, program other devices on the 


MULTICHANNEL 
bus, resolve and grant bus priori- 


ty to other devices, monitor 
bus status, handle bus 


interrupts 
and control 
the 
MULTICHANNEL 
bus 


reset line. All of these functions 
are maintained 
by 


the on-board 
firmware 
based on parameter 
inputs 
from the host. Please refer to the MULTICHANNEL 
BUS SPECIFICATION 
for detailed 
descriptions 
of 


these modes. 


iSBX™ Bus Capabilities 


The iSBC 589 Controller 
contains 
two 
iSBX con- 


nectors 
which 
can support 
either 
8-bit or 16-bit 


MULTIMODULE 
boards. The iSBX connectors 
are 


situated 
so that either two single-wide 
modules 
or 


one 
single-wide 
and 
one 
double-wide 
MULTI- 
MODULE board may be installed. 
A wide variety of 


standard 
peripheral 
controllers 
and 
analog 
and 


digital 
I/O MULTIMODULE 
boards 
are currently 


available. 
In addition, 
the iSBX connectors 
provide 


an opportunity 
to add over 30 square 
inches 
of 


user 
designed 
hardware 
to the 
iSBC 589 board 
which can be used to implement 
specialized 
I/O in- 


terfaces. 
For more 
information 
on specific 
iSBX 


MULTIMODULE 
boards, 
consult 
the 
Intel 
OEM 
Microcomputer 
System 
Configuration 
Guide. 


M U LTIBUS® Capabilities 


MULTIBUS system 
memory and I/O resources 
may 


be used as the source 
or the destination 
for an 


iSBC 589 board transfer 
operation. 
The iSBC 589 
DMA Controller 
may also be used as a high-speed 
data 
mover 
to transfer 
blocks 
of data 
from 
one 


MULTI BUS system RAM area to another. MULTIBUS 
system 
memory 
may also be used to store Param- 


eter Blocks 
to be executed 
by the on-board 
firm- 


ware package. 
The iSBG 589 board, 
acting 
as a 


MULTI BUS Master, can access up to 16 megabytes 
of MULTI BUS memory 
and up to 64K MULTIBUS 
I/O locations. 


Two 
MULTI BUS transfer 
modes 
are 
available. 


Selection 
of 
the 
desired 
mode 
is done 
via the 
Parameter 
Block_ Transfer 
rates 
of 
up to 
900K 
bytes 
per second 
may be achieved 
in shared 
bus 
mode, where the iSBC 589 board requests 
access 
to the system 
bus for 1.4 microseconds 
to transfer 
one byte or word to or from memory. 
In BUSLOCK 
mode, 
the 
iSBC 
589 is established 
as the 
sole 
master 
which 
may access 
the system 
bus for the 
duration 
of the block 
data transfer. 
In BUSLOCK 
mode, the iSBC 589 board can transfer 
up to one 
megabyte 
per second. 


User Command Interface 
Firmware Package 


The iSBC 589 board 
is supplied 
with 
a firmware 
package 
contained 
in two 
Intel 
2732A 
EPROMs 
that greatly simplifies 
programming 
by providing 
a 
high 
level 
software 
interface 
to 
the 
on-board 
resources. 
In the 
majority 
of 
applications, 
the 
board 
may be programmed 
entirely 
via the firm- 


ware and without 
writing 
any 8089 lOP assembly 
language 
code. 
The firmware 
package 
supports 
the two channel 
operation 
of the 8089 lOP. Each 
channel 
has its own Parameter Block area contain- 


ing the required 
information 
for independent 
chan- 


nel operation. 


To invoke an I/O operation, 
the user creates one or 
more Parameter 
Blocks in memory which describe 
the desired 
operation. 
The firmware, 
which 
con- 


sists 
of a series 
of 8089 lOP assembly 
language 
task programs, 
will interpret 
the Parameter 
Blocks 


to configure 
the board's 
interfaces 
or to perform 
byte, word or DMA block 
transfers. 
Each Param- 
eter 
Block 
consists 
of a command 
byte, 
status 
byte, 
data 
source 
and 
destination 
pointers 
and 


other 
information 
as shown 
in Table 
1. Commands 


recognized 
by the firmware 
package 
are listed 
in 
Table 
2. The 
Execute 
User 
Task 
command 
is of 
special 
interest 
because 
it allows 
the user to ex- 
tend the capabilities 
of the iSBC 589 board by add- 
ing his own 8089 lOP assembly 
language 
routines 
to the firmware 
package, 
while 
retaining 
the struc- 
ture 
and standard 
functions 
supplied 
by the firm- 
ware. 


Table 1. User Command 
Interface 
Firmware 


Parameter 
Block Byte Format 


Command Byte 
Status Byte 
Command Chaining Pointer 
Command Chaining Pointer 
Command Chaining Pointer 
Command Chaining Pointer 
Device Number 
MULTICHANNEL Data Type 
Memory Pointer or Register Number 
Memory Pointer or Register Number 
Memory Pointer or Data Storage Location 
Memory Pointer or Data Storage Location 
Device Number 
MULTICHANNEL Data Type 
Memory Pointer or Register Number 
Memory Pointer or Register Number 
Memory Pointer 
Memory Pointer 
Byte Counter 
Byte Counter 
Byte Counter 


In addition 
to executing 
transfer 
operations, 
the 
firmware 
package 
executes 
an 
initialization 
se- 


quence 
which 
prepares 
the 8089 lOP and the on- 
board 
RAM, EPROM 
and I/O resources 
for further 
firmware 
execution. 


RAM Capabilities 


In its standard 
configuration, 
the iSBC 589 board 


contains 
8K 
bytes 
of 
high-speed, 
dual-ported 


static 
RAM. The first 
256 bytes 
are dedicated 
for 


use by the on·board 
firmware. 
The remaining 
on- 


board 
RAM 
may 
be 
used 
for 
storing 
additional 


Parameter 
Blocks 
for the firmware 
or as a data buf· 


fer for I/O operations. 
This 
memory 
is always 
ad- 


dressed 
by the 
8089 
lOP as locations 
OOOOHto 


1FFFH. 
However, 
for 
MULTIBUS 
accesses 
through 
the dual-port, 
the RAM base address 
may 
be configured 
on any 8K-byte 
boundary 
in the first 


megabyte 
page of the 
MULTIBUS 
memory 
space. 


Users 
may 
install 
additional 
on-board 
RAM 
by 


placing 
two 
byte-wide 
RAMs 
in the 28-pin 
JEDEC 


standard 
sockets. 
The additional 
RAM is accessi- 


ble only 
by the on-board 
8089 lOP. 


EPROM Capabilities 


The iSBC 589 board 
can be configured 
with 
up to 


32K bytes 
of non-volatile 
read only 
memory. 
Four 


28-pin 
sockets 
are 
provided 
for 
the 
use 
of 
Intel 
2716,2732 
and 2764 EPROMs 
or byte-wide 
RAMs. 


Command 
Description 


NO-OP 
Test the intelligent 
slave interface 
on the iSBC 589 board. The board reads the 
Parameter Block, generates status and interrupts 
the host on completion. 


REGISTER WRITE 
Write either a word or byte of data from the Data Storage Location within the Param- 
eter Block to the location 
specified 
by the Parameter Block Device Number and 
Register Number. 


REGISTER READ 
Read either a word or byte of data from the location 
specified 
by the Parameter 
Block Device Number and Register Number to the Data Storage Location within the 
Parameter Block. 


PERFORM DMA 
Transfer data beginning 
at the location 
specified 
by the source Memory Pointer, 


Device Number and Register Number parameters to the location 
specified 
by the 
destination 
Memory Pointer, Device Number and Register Number parameters. The 
number of transfers 
is specified 
by the Byte Count parameter. A Byte Count of 0 
enables DMA until an external terminate condition 
is sensed. 


EXECUTE USER TASK 
Transfer 8089 lOP program execution from the Firmware Package to a user defined 
8089 assembly language routine beginning at the location specified by the Memory 
Pointer parameter. Upon completion, 
the user task returns control to the firmware. 


In the default 
configuration, 
the board 
is jumpered 


for 32K devices, 
and, two 2732A EPROMs 
contain- 


ing the firmware 
package 
are installed. 
Users who 


wish 
to 
extend 
the 
capabilities 
of 
the 
firmware 


may do so by programming 
unused 
locations 
in 


the 
firmware 
PROMs, 
installing 
two 
additional 


2732A 
PROMs 
or copying 
the firmware 
into 2764s 


along 
with 
their 
own 
code. 
As an alternative, 
two 


byte-wide 
RAMs 
of equal 
or smaller 
capacity 
may 


be installed 
in the open 
sockets 
and used in con- 


junction 
with 
the firmware 
PROMs. 


Programmable 
Interval Timers 


Three 
independent, 
fully 
programmable 
16-bit 
in- 
terval/event 
counters 
are provided 
by an 8254-12 


Programmable 
Interrupt 
Timer. 
Each counter 
may 


operate 
in either 
BCD or binary 
mode. One counter 


is 
used 
by 
the 
firmware 
package, 
leaving 
two 


counters 
available 
to 
the 
firmware 
user. 
These 


timers 
may be used 
for a variety 
of on-board 
and 


off-board 
functions 
including 
timed-interval 
DMA 


requests 
and 
terminations 
or fail 
safe 
time 
out 


control 
for I/O operations. 


System 
Development 
Capabilities 


For applications 
where 
it is necessary 
to extend 
the 
User Command 
Firmware 
Package 
by writing 


additional 
8089 lOP assembly 
language 
code, 
the 


development 
cycle 
can 
be significantly 
reduced 
and simplified 
by using 
the Intellec 
Series 
Micro· 


computer 
Development 
Systems. 
The 
8089 
lOP 


Software 
Support 
Package 
which 
includes 
a 


Macro 
assembler, 
linker, 
locater 
and PROM 
map- 
per is supported 
by the 
ISIS·II disk·based 
operat· 


ing system. 


In-Circuit 
Emulator 


The ICE·86A or ICE-86 and ICE-86U upgrade 
kit pro- 


vide 
the necessary 
link 
between 
the software 
de· 


velopment 
environment 
provided 
by the 
Intellec 


system 
and the "target" 
iSBC 589 execution 
sys· 


tem. In addition 
to providing 
a mechanism 
for load· 


ing executable 
code 
and 
data 
into 
the 
iSBC 
589 
board, 
the In-Circuit 
Emulator 
provides 
a sophisti· 


cated 
command 
set to assist 
in debugging 
soft- 


ware and in final 
integration 
of the user hardware 


and software. 


SPECIFICATIONS 


8089 lOP 


Instruction 
- 
16 to 40-bits 


Data - 
8, 16-bits 


System Access 
Time 


Dual·port 
Memory 
- 
550 
nanoseconds 
(worst 


case, without 
contention 
from 
on-board 
access) 


I/O Capacity 


MULTICHANNEL 
I/O Bus 
- 
1 MULTICHANNEL 


port which 
supports 
8 and 16·bit transfers 
and can 


be 
configured 
as 
a Basic 
Talker/Listener, 
Con- 


troller 
or Supervisor 


iSBXTM MULTIMODULETM 
- 
Two (2) iSBX MULTI- 


MODULE 
boards 


Interface 
I/O Addresses 


iSBX Connector #1 
FF80 thru FF9F 


iSBX Connector #2 
FFAO thru FFBF 


MULTICHANNEL 
FFDO thru FFEE 


Interval Timer 
FFC8 thru FFCE 


Other On-board Devices 
FFCO thru FFC6 
FFFO thru FFFE 


Memory Capacity 


ON· BOARD 
EPROM 


Device 
Total 
Capacity 


2716 
8K bytes 
2732A 
16K bytes 
2764 
32K bytes 


ON· BOARD 
RAM 


Total 
Capacity 
- 
8K bytes 


On-Board 
Address 
- 
00000·01 FFFH 


MULTIBUS@Address 
- 
Jumper 
selectable 
on 8K 


byte boundaries. 
Default 
is 0H. 


Address 
Range 


FEOOO·FFFFFH 
FCOOO·FFFFFH 
F8000-FFFFFH 


iSBXTM 
MULTIBUS® 
On-Board 
MULTICHANNEL 


Shared 
Buslock 
RAM 


MULTICHANNEL 
- 
2.0 
2.4 
2.2 
1.8 


iSBX 
2.0 
2.0 
2.4 
2.2 
2.0 


MULTIBUS (Shared) 
2.4 
2.4 
2.8 
- 
2.2 


MULTIBUS (Busloek) 
2.2 
2.2 
- 
2.4 
/ 
2.0 


On-Board RAM 
1.8 
1.8 
2.2 
2.0 
1.6 


Timers 


Input 
Frequencies 
- 
Jumper selectable at 1.25 
MHz, 625 KHz or 312.5 KHz 


Output 
Frequencies/Timing 
Intervals 
- 


Single Timer/Counter 
Dual Timer/Counter 


Function 
(Two Timers 
Cascaded) 


Minimum 
Maximum 
Minimum 
Maximum 


Real-time delay 
1.6 usee 
210 msee 
3.2 usee 
1.37x 10' see 


Programmable one-shot 
1.6 usee 
210 msee 
3.2 usee 
.1.37x 10' see 


Rate generator 
4.76 Hz 
625 KHz 
7.3xlO-5Hz 
312.5 KHz 


Square-wave rate generator 
4.76 Hz 
625 KHz 
7.3 x 10-5 Hz 
312.5 KHz 


Software triggered strobe 
1.6 usee 
210 msee 
3.2 usee 
1.37x 10' see 


Hardware triggered strobe 
1.6 usee 
210 msee 
3.2 usee 
1.37 x 10' see 


Interface 
Double-Sided 
Centers 
Mating 
Connectors· 
Pins (qty.) 
(in.) 


MULTIBUS 
86 
0.156 
ELFAB BS1562043PBB 


System Bus 
Viking 2KH43/9AMK12 Soldered PCB Mount 
EDAC 337086540201 
ELFAB BW1562D43PBB 
EDAC 337086540202 
ELFAB BW1562A43PBB Wire Wrap 


Au.xiliary Bus 
60 
0.100 
EDAC 345060524802 
ELFAB BS1020A30PBB 
EDAC 345060540201 
ELFAB BW1020D30PBB Wire Wrap 


iSBX Bus (2) 
36 
0.100 
iSBX 960-5 


MULTICHANNEL Bus 
60 
0.100 
3M 3334-6000 
BERG 65949-960 


Interfaces 


MULTIBUS® 
- 
All signals 
TTL compatible 


MULTICHANNEL 
- 
All signals 
TT.L compatible 


iSBXTM Bus - 
All signals 
TTL compatible 


Timers 
- 
All signals 
TTL compatible 


Auxiliary 
Power/Memory 
Protect 


There 
is no provision 
made on the iSBC 589 board 
for battery 
backup 
of RAM or for power 
fail detec- 
tion. 


Function 
Characteristic 
Sink Current 
(mA) 


Data 
Tri-state 
32 


Address 
Tri-state 
32 


Commands 
Tri-state 
32 


Physical 
Characteristics 


Width 
- 
12.00 in (30.48 em) 


Height 
- 
7.05 in (17.9 em) 


Depth 
- 
.50 in (1.27 em) 


Weight 
- 
16 oz (453.6 gm) 


Environmental 
Characteristics 


Operating 
Temperature 
- 
O·C to 55·C 


Relative 
Humidity 
- 
to 90% 
(without 
condensa- 


tion) 


Electrical 
Characteristics 


DC POWER 
REQUIREMENTS 


Configur,ation 
Current 
Requirements 


(+ 5V + 5"10 maximum) 


Without 
EPROM 
4.7 amps 


With 8K EPROM 
5.4 amps 
(using four 2716s) 


With 8K EPROM' 
5.0 amps 
(using two 2732As) 


With 16K EPROM 
5.3 amps 
(using four 2732As) 


With 32K EPROM 
5.3 amps 
(using four 2164s) 


Reference 
Manuals 


142996·001 
- 
iSBC 589 Intelligent 
DMA Controller 


Board 
Hardware 
Reference 
Manual 
(Not Supplied) 


142686·001 
- 
Intel 
iSBX 
Bus 
Specification 
(Not 


Supplied) 


143269·001 
- 
Intel 
MULTICHANNEL 
Bus Specifi- 


cation 
(Not Supplied) 


Manuals 
may be ordered 
from 
any Intel 
sales 
rep· 


re~entative, 
distributor 
office 
or from 
Intel 
litera- 


ture Department, 
3065 Bowers 
Avenue, Santa Clara, 


California 
95051 


Part Number 


SBC 589 


Description 


Intelligent 
DMA Controller 
Board 


iSBC® 580 MULTICHANNEIlM 
BUS 


TO iLBX™ BUS INTERFACE 


• MULTICHANNELTMI/O bus 16-bit 


Talker/Listener 
interface 


• Data rates up to 5.3 megabytes per 


second 


• iLBX™ bus master interface (primary or 


secondary) 


• Addresses up to 16 megabytes of 


iLBXTMbus memory 


The iSBC@580 Interface 
Board is a member 
of Intel's complete 
line of MULTIBUS@ microcomputers 
which maxi- 
mize system performance 
by using separate 
optimized 
buses for intra-system 
communication 
(MULTIBUS 
system 
bus), high speed 1/0 (MULTICHANNEL™ 
DMA 1/0 bus), expansion 
1/0 (iSBX™ I/O expansion 
bus) and high-speed 
memory expansion (iLBX™ execution 
bus). The iSBC 580 board provides a key element in the enhanced 
MULTIBUS 
system architecture 
by implementing 
a MULTICHANNEL 
1/0 bus to iLBX bus interface on a single 6.75 x 12.00 inch 
printed circuit board. Using an LSI state machine with standard on-chip firmware to maximize throughput, 
the on-board 
Intel@8048 Single Component 
Microcomputer 
transfers 
data between a MULTICHANNEL 
Controller, 
device and up 


to 16 megabytes of iLBX bus resident memory at rates up to 5.3 megabytes per second. Acting as a MULTICHANNEL 
TalkerlListener, 
the iSBC 580 board increases 
the system's 
overall performance 
by transferring 
data between the 
MULTICHANNEL 
1/0 bus and system memory without 
using the MULTIBUS 
system bus. As shown in Figure 1, this 
allows other system tasks to utilize MULTI BUS resources while high-speed 1/0 block transfers are occurring simultane- 
ously. The board's high throughput 
and independence 
from MULTI BUS activities make it an ideal solution for applica- 
tions that must transfer large amounts of data in and out of a MULTI BUS system, such as MULTI BUS to host computer 
links and mass storage, 
graphics 
display 
and high-speed 
data acquisition 
subsystem 
interfaces. 


FUNCTIONAL 
DESCRIPTION 


MULTICHANNELTM 
Interface 
Capabilities 


The MULTICHANNEL 
I/O bus is designed 
to provide a 
general 
purpose, 
high-speed 
data 
path 
between 
a 


microcomputer 
system and up to 15 block transfer 
de- 


vices. Using a 16-bit wide data bus and a simple asyn- 
chronous 
handshaking 
scheme, 
the MULTICHANNEL 


bus can operate over distances up to 15 meters (50 feet) 
with a maximum 
burst throughput 
of 8 megabytes/sec- 
ond. The bus consists 
of 16 address/data 
lines, 6 con- 


trol lines, 2 interrupt 
lines, parity lines and reset. Via 


these signals, 
a MULTICHANNEL 
Supervisor 
or Con- 


troller 
may configure 
and then 
initiate 
a block 
data 


transfer 
with any other device on the bus. 


The iSBC 580 board acts as a 16-bit only Talker/Listener 
device 
on the MULTICHANNEL 
I/O bus. As a Talker/ 


Listener, 
the board will respond 
to Register 
Read or 


Write and DMA requests issued by the MULTICHANNEL 
Supervisor 
(typically an iSBC 589 board) or by a MULTI- 


CHANNEL 
Controller 
device. 


The iSBC 580 board implements 
32 MULTICHANNEL 


Device Registers. The first three registers are the stand- 
ard STO Status, SRQ Status and SRQ Mask Registers, 
as defined 
by the MULTICHANNEL 
Bus Specification. 
The remaining 
registers are used to communicate 
with 


the on-board 
firmware 
and for user data storage. 
The 


firmware 
operations 
which 
may be initiated 
by writing 


to the Command 
Register 
are listed 
in Table 
1. The 


iSBC 580 board 
always 
sends 
and receives 
a 16-bit 


word on the MULTICHANNEL 
interface 
but, the iSBC® 


580 device registers (see Table 2) are 8-bit only. Register 
Write operations use only the low order 8-bits (ADO-AD?). 
Register Read operations place the data on the low order 
data lines of the MULTICHANNEL 
I/O bus and set the 
high order data lines to FFH. 


Command 
Operation 
Code (Hex) 


0 
No Operation 


1 
Go off line forever 


2 
STO poll (diagnostic) 


3 
SRQ poll (diagnostic) 


4 
Set on-board 
timer 


5 
Read on-board 
timer 


6 
Start 
on-board 
timer 


7 
Stop on-board 
timer 


8 
Generate 
Task Complete 


interrupt 


9 
Perform 
checksum 
on firm- 


ware (diagnostic) 


A 
Turn on-board 
lED 
on 


B 
Turn on-board 
LED off 


C 
Reset 


D,E 
Reserved 


F 
Set interrupt 
mask 


10 
Read 
interrupt 
mask 


11-lF 
Reserved 


Figure 
1. iSBC®S80 
board, 
configured 
as an iLBX™ Bus Primary 
Master, 
transfers 
data between 
iLBX™ 


memory 
and MULTICHANNEL.'M devices 
without 
using 
the system 
bus. The iSBC®S89 
board 
acts as the MULTICHANNEL.'M Supervisor 
and performs 
data transfers 
between 
MULTIBUS®memory 
and MULTICHANNEL.'M devices. 
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The iSBC 580 board can generate 
maskable 
MULTI- 


CHANNEL 
STO interrupts 
when the board detects 
a 


parity error in incoming 
MULTICHANNEL 
data, when 


the board attempts to address non-existent iLBX memory 
or when the board detects a MULTIBUS 
interrupt 
from 


the system in which it resides. The last type of interrupt 
allows a single board computer 
to send an interrupt 
via 


the iSBC 580 board to the MULTICHANNEL 
Supervisor 


located 
in another 
MULTIBUS 
system. 
The board can 


also generate a number of SRQ interrupts on the MULTI- 
CHANNEL 
bus as shown in Figure 2. 


X 
Don't care 


lM 
iLBX ™ 
lock/mask 
TOM: 
Time out mask (STO) 
PEM: 
Parity error mask (STO) 
MIM: 
MULTIBUS' interrupt mask (STO) 
FPE: 
Forced Parity Error mask 


Figure 
2. 
iSBC® 580 Interrupt 
Mask Register 
(14H) 


iLBXTMBus Interface 
Capabilities 


Used in conjunction 
with the MULTIBUS 
interface, 
the 
iLBX bus is designed 
to provide off-board 
memory and 


I/O expansion 
for single board computers 
while main- 
taining on-board 
performance. 
The iLBX bus provides 
high-speed 
access to compatible 
expansion 
boards by 
granting 
privileged 
use of the bus to a single Primary 
Master. The bus also provides 
limited 
access to iLBX 


bus expansion 
boards for, at most, one Secondary 
Mas- 


ter that requires only occasional 
or non-concurrent 
ac- 
cess to iLBX resources. 
The iLBX bus, with 
16 data 


lines, 24 address lines plus control, parity and interrupt 
signals, utilizes all the pins on the P2 connector 
except 
the four pins dedicated 
to the high-order 
address 
lines 
of the MULTIBUS 
interface. 
The non-multiplexed 
ad- 


dress and data lines provide access to up to 16 mega- 
bytes of iLBX bus resident memory, on up to 4 separate 
expansion 
boards, 
at speeds 
comparable 
to that of a 


single board computer's 
on-board 
resources. 


The iSBC 580 board is configurable 
as either a Primary 
or a Secondary 
Master on the iLBX bus. Figure 1 shows 


a typical system configuration, 
with an iSBC 580 board 
acting as a Primary 
Master. The board can access up 
to 16 megabytes 
of iLBX memory. 
Supporting 
16-bit 


transfers 
on the MULTICHANNEL 
bus, the board ac- 
cesses memory as 16-bit words on even byte iLBX ad- 
dress boundaries. 
To increase the performance 
of iLBX 


memory 
read 
operations, 
the 
iSBC 
580 board 
pre- 


fetches data from memory while the current data word 
is being transferred 
over the MULTICHANNEL 
I/O bus. 


Register 
Address 


STO Status 
OOH 


SRQ Status 
01H 


SRQ Mask 
02H 


RESERVED 
03H-OFH 


General Purpose Registers 
10W-1FH 


• NOTE: 
10H used as Command Register. 


Table 
2. 
iSBC®580 
MULTICHANNEL™ 
Device 


Register 
Set 


Device 
Address 
- 
Jumper 
selectable 
between 
DOH 


and OEH 


Registers 
- 
STO status, SRQ status, SRQ mask plus 


device specific 
registers 


Addressing 
- 
16 megabytes 
on even byte boundaries 


only 


Signal 
Level 
- 
TTL compatible 


Data - 
None 


Addressing 
- 
None 
' 


Interrupts 
- 
Jumper configurable 
to use any 1 of the 8 


MULTI BUS interrupt lines, Interrupts are edge triggered, 


Signal 
Level 
- 
TTL compatible 


iLBXTMBus 


Interface 
- 
Primary 
or Secondary 
(default) 
Master 
Throughput 


Transfer 
Mode - 
16-bit 
5,3 megabytes/sec 
(2.65 megatransfers) 
max, 
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iLBX™ BUS INTERFACE 


Double-Sided 
Pins - 
60 


Centers 
- 
0.100 in. 


Mating 
Connectors' 
- 
Kelam RF30-2803-5 
T&B Ansley A3020 
(609-6025 
modified) 


MULTICHANNEL™ 
BUS INTERFACE 


Pins- 
60 


Centers 
- 
0.100 in. 


Mating 
Connectors' 
- 
3M 3334-6000 
Berg 65949-960 


• Connectors compatible with those listed may also be used. 


Physical Characteristics 


Width 
- 
12.00 inches (30.5 em) 


Height 
- 
6.75 inches (17.1 em) 


Depth 
- 
0.60 inches (1.5 em) 


Weight 
- 
12 ounces 
(340 gm) 


Operating 
Temperature 
- 
0° to 55°C 


Relative 
Humidity 
- 
to 90% (without 
condensation) 


DC Power Requirements 


Voltage 
- 
+ 5 volt only ± 5% 


Current 
- 
2.5 amps (typical) 


Reference Manuals 


144457-001 
- 
iSBC 580 MULTICHANNEL 
to iLBX Bus 


Interface 
Board 
Hardware 
Reference 
Manual 
(NOT 


SUPPLIED) 


143269-001 
- 
Intel MULTICHANNEL 
Bus Specifica- 


tion (NOT SUPPLIED) 


144456-001 
-Intel 
iLBX Bus Specification 
(NOT SUP- 


PLIED) 


142996-001 
- 
iSBC 589 Intelligent 
DMA Controller 


Board Hardware 
Reference 
Manual (NOT SUPPLIED) 


Manuals may be ordered from any Intel sales represen- 
tative, distributor 
office or from Intel Literature 
Depart- 


ment, 3065 Bowers Avenue, 
Santa Clara, CA 95051 


Part Number 
Description 


SBC 580 
MI.JLTlCHANNEL 
to iLBX Bus 


Interface 
Board 


inter 


iSBC® 570, 576, 577 
INTEL SPEECH TRANSACTION FAMILY 


• Friendly man-machine interface- 
speech is the most natural and most 
easily learned form of interaction for 
man. 


• Lower data entry cost-source 
data 
capture 


• Higher accuracy-operator 
mental 
encoding is eliminated. 


• Freedom of Movement-More 
efficient 
work flow 


• Hands and eyes free-ability 
to 
perform another primary task 


• Easier training-interactive, 
generic 
terminology 


• Complements keyboard/CRT-new 
dimension to data entry 


Users world wide are recognizing 
the many advantages 
of having Automatic 
Speech Recognition 
(ASR) and 
Electronic 
Speech Synthesis (ESS) in their products 
and applications. 
Speech I/O is a new dimension 
in data 
entry/control 
that complements 
other I/O mechanisms. 


Speech I/O as a direct man-machine 
interface 
can be used for a broad range of applications, 
such as office and 
factory 
automation, 
computer-aided 
design, 
QC inspection 
stations, 
inventory 
control-and 
many 
more. 


Whatever 
your application 
is, the benefits of speech I/O are measured 
in dollars saved, improved 
productivity 
and improved 
product 
quality. 


The following 
afe trademarks 
of Intel Corporation 
and its affiliates 
and may be used only to identify 
Intel products: 
exp, CREDIT, i, ICE, les. 1m, Insita. 
Intel, 
INTEL, 
lntelevision, 
Intellee, 


iMMX, 
iOSP, 
iPDS, 
iRMX, 
,sec, 
iSBX, 
Library 
Manager, 
MeS, MULTIMODULE, 
Megachassis, 
Micromainframe, 
Micromap, 
MULTreUS, Multichannel, 
Plug-A-Bubbte, 
PROMPT, 


Promware. 
RMXJ80, 
System 
2000, UP I, and the combmation 
of leS, 
iAMX. ,sec, ISBX, ICE, MeS, or UPI and a numericat 
suffix 
Intel Corporation 
Assumes 
No Responsibility 
for the use 


of Any Circuitry 
Other Than Circuitry 
Enbodied in an Intel Product. No Other Patent licenses 
are implied 
©INTEl 
CORPORATION, 1982 
FEBRUARY 1983 
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In computer-aided 
design 
and 
manufacturing 


(CAD/CAM), design commands 
by speech allow the 


design engineer to keep his attention focused on the 
actual graphic elements. 


In manufacturing, 
speech transactions 
provide 
im- 


portant 
advantages 
in productivity. 
Defect tracing, 
production 
line monitoring 
and synchronization, 
and 


factory data collection, 
all benefit from direct human 


speech to computer 
communication. 


In the automated 
office, ever-increasing 
machine in- 


telligence 
can be controlled 
without 
mastering 
of 


typing 
skills. 


The basic concept of a speech I/O system is shown in 
Figure 1. The speech I/O system provides a human- 
oriented 
interface 
with 
a 
machine-oriented 


computer-based 
information 
system or process. The 


speech 
I/O system 
recognizes 
speech 
inputs, 
pro- 


vides 
visual/audio 
prompts 
and verification, 
and 


handles message editing 
and buffering. 
Depending 


on what was recognized, 
digitally coded data is then 


used 
to 
interact 
with 
the 
machine-oriented 


computer-based 
system. 


The functional 
blocks 
of a speech 
I/O system are 


shown in Figure 2. 


( 
PROMPT) 


SPEECH 
TRANSACTION 
PROCESSING 


A complete system includes 
not just the capabilities 


for signal conditioning, 
Automatic 
Speech Recogni- 


tion (ASR), and Electronic 
Speech Synthesis 
(ESS), 


but must include 
speech transaction 
processing 
as 


well. 
The 
Speech 
Transaction 
Processing 
task 
includes: 


-The 
conversion 
between 
spoken 
language 
and 


coded representation 
-Operator. 
prompting 
and feedback 


-Message 
editing 
-Message 
buffering 


In addition, 
development 
tools should 
be available 


for the generation 
of speech transaction 
files that 


will define the operations 
of the speech I/O system. 


Figure 3 shows the function 
of each member of the 


Intel Speech Transaction 
Family. 


The Intel 
Speech 
Transaction 
Family, iSBC$ 
570, 


iSBC® 576 and iSBC® 577, is a family of products that 
provides 
a minimal 
risk 
path 
to add 
speech 
In- 


put/Output 
(I/O) to your 
product 
line. The Speech 


Transaction Family will allow you to move from evalu- 
ation 
to integral 
speech 
driven 
products 
without 


major redesigns. Depending 
on your stage of prod- 


uct development, 
whether 
it is an evaluation, 
or a 


product simulation, 
or an add-on speech option, or a 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
DIGITALLY CODED DATA 
COMPUTER·BASED 


INFORMATION 


SYSTEM OR PROCESS 


NOTES: 
1. INTERACTIVE 
2. CONVERSION BETWEEN SPOKEN LANGUAGE AND CODED REPRESENTATION 
3. PROMPTING & FEEDBACK TO OPERATOR 
4. MESSAGE BUFFERING 
5. MESSAGE EDITING 


inter 


SPEECH 
TRANSACTION 
GENERATOR 


fully integrated speech product, the Speech Transac- 
tion Family's flexibility 
allows your speech I/O appli- 


cation to grow with a minimal amount of engineering 
effort. The Speech Transaction 
Family allows you to 


adapt your product to various markets as your appli- 
cation 
needs 
change, 
without 
a major 
redesign. 


Whether it is a configured 
speech development 
sys- 


tem, or easy-to-integrate 
speech board. or a maxi- 


mum value-added 
speech 
component 
chip set, an 


Intel product 
is ready to meet your needs. 


Development 
of your speech 
I/O system may have 


been your stumbling 
block in the past. The require- 


ment 
for 
speech 
technology 
expertise, 
extensive 


hardware 
development 
and extensive software 
de- 


velopment 
are a thing 
of the past. Integral to the 


Speech Transaction 
Family are highly sophisticated 


computer-based 
design and development 
tools that 


will take you from 
product 
concept 
to a working 


speech 
product 
with 
a minimal 
effort. 
In-depth 


knowledge 
of speech 
algorithms 
and of speech 


human factors considerations 
are no longer an abso- 
lute requirement 
of your system designers. 


Intel provides the total 
solution. 
Speech 
hardware 


has been designed to work with our wide selection of 
Multibus<!ll single-board 
computers, 
memory 
cards, 


and data I/O cards. Speech software is based on the 
Real-Time 
Multi-Tasking 
Executive 
(RMX-88). 


Speech transaction 
software development 
has been 


implemented 
on our universal 
Intellec<!llMicrocom- 


puter Development 
System. All of the pieces have 


been engineered 
to provide.. an easily 
integrated 


speech I/O solution. 


Speech I/O is a new technology 
area. Intel has devel- 


oped a family of products 
and services, that will fit 


your development 
sequence 
needs for a new tech- 


nology 
with 
minimal 
risk and ease of use. A very 


likely 
evaluation 
and development 
sequence 
you 


may follow 
is illustrated 
in Figure 
4 and Figure 
5 


along with Intel's products 
and services that are of- 


fered to meet those needs. Having products and ser- 
vices that can satisfy the illustrated sequence is very 
important 
in reducing the risk, engineering 
cost, and 


lowering 
incremental 
investments 
necessary 
as 


product 
requirements 
change. 
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NOTES: 


• MAY BE PURCHASED AS SPEECH TRANSACTION 
CHIP SET (iSBC· 
577) 


•• CONTACT INTEL 


SPEECH 
TRANSACTION 
GENERATOR 


TECHNOLOGYI 


PRODUCT 
INVESTIGATION 
AND EDUCATION 
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USING 


TECHNOLOGY 
EVALUATION 
AND DEMO 


DESIGN PHASE, 


APPLICATION 
STUDIES, 


FLOW CHARTS 
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USING 


APPLICATION 
SIMULATION 
& 


SPEECH I/O 
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SPEECH 
TRANSACTION 
SOFTWARE 
DEVELOPMENT 
AND TEST 


iSBC"XXXG 
t 
USING 


INITIAL 
SPEECH I/O 
ADD-ON 
PRODUCT 


FULLY INTEGRATED 
MAXIMUM 
VALUE- 


ADDED SPEECH 
I/O 


The sequence starts with a workshop to learn about 
the Speech Technology 
and to develop a necessary 
knowledge 
base to evaluate potential 
applications. 


The next stage, an evaluation-oriented 
Speech Trans- 
action 
Development 
System (iSBC'" 570 and Intel- 
lec® Microcomputer 
Development System), provides 


technology 
evaluation 
and demonstrations 
Without 


engineering 
investment. 
Using the experience 
from 
the two previous stages, plus field and factory appli- 
cation support, 
the design phase can now proceed. 


Once the application 
framework 
has been estab- 
lished, 
appllcallon 
simulation 
can 
be performed 


using the Speech Transaction Development 
System. 


Upon 
successful 
completion 
of simulation 
the 


speech 
transaction 
software 
development 
can be 


easily completed 
on the same Speech Transaction 


Development System. The initial speech I/O products 
can then be shipped 
using the Speech Transaction 


Board 
(iSBC® 576). When 
higher 
volume 
justifies 


increasing the value added, the chip set, iSSCiI!l577, 
can be used. Throughout 
the process, whether 
it i 


system, 
board, 
or chip 
set, the same software 
is 


utilized. 
Very little 
is lost as your 
product 
needs 
change. The level of investment 
required tracks the 


stage of product 
development. 
Your risk and expo- 


sure is kept to a minimum. 
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SPEECH APPLICATION DESIGN WORKSHOP 


"SPEECH COMMUNICATION WITH COMPUTERS" 


• 
4-day "hands-on" experience 


• 
Understanding of application design 
involving speech input 


• How to evaluate speech recognition 


performance 


• Use of Intel speech development tools 


• Application selection criteria for 


speech I/O 


• Interfacing to host system 


The Intel Speech Design Workshop 
is an intensive four days that will result in an understanding, 
based on 
experience, 
of speech as an input method. The experienced 
system designer 
via laboratory 
and lecture 
will 
rapidly 
develop 
an understanding 
of the 
capabilities 
and. limitations 
of speech 
recognition 
as an input 
peripheral 
system. This is an ideal first step toward mastering 
the exciting 
new technology 
of speech transac- 
tion processing. 
All persons directly 
involved in the selection or implementation 
of a speech recognition-based 
system should attend. Attendees are presumed to be familiar 
with computers, 
a programming 
language, and 
the Intellec~ Microcomputer 
Development 
System. The student will experience 
all phases of solution 
develop- 
ment 
by designing, 
implementing, 
testing, 
and presenting 
to the class an extension 
to the basic speech 
demonstration 
provided 
with the Speech Transaction 
Development 
Set. 


What's 
unique 
about 
speech?-Communicating 


with computers 
using words and phrases rather than 


keystrokes. 


Introduction 
to the Speech Transaction 
Board (STB), 
Speech Transaction 
Manager 
(STM), Speech Trans- 


action 
File 
(STF), 
and 
the 
Speech 
Transaction 


Generator 
(STG). 


Lab: Install iSBC~ 570 Speech Transaction 
Develop- 


ment 
Set. 
Operate 
Speech 
Training 
Demo 


Program. 


Lab: Using the Evaluation 
mode to ascertain 


performance. 


The Speech Transaction 
File (STF) using the training 


demonstration 
program 
as an example. 


Lab: Develop 
an extension 
of the training 
demon- 
stration 
program 
using the STG. 


Automatic 
Speech Recognition 
(ASR) subsystem 


parameters. 


Lab: Evaluate performance 
of new STF developed on 


Day 
2. Measure 
effects 
of 
ASR 
parameter 


changes on recognition. 


Lab: Discuss student-developed 
program 


extensions. 


iSBC® 570 


SPEECH TRANSACTION DEVELOPMENT SET 


• Complete Development Support Set for 


the Intel Speech Product Family. 
Includes: 


-Speech 
Transaction Generator 
-iSBC® 
576 Speech Transaction Board 


-iSBC® 
575 Operator Control Unit 


-Microphone 
-Demo 
program 
-Speech 
Transaction Design Manual 


• 
Intellec® Microcomputer Development 
System based 


• Speech Transaction Generator 


provides: 
-Interactive 
design environment 


.-A 
speech transaction structure 


embodying good human factors 
engineering 
-Automatic 
error checking of 


transaction design 
-Symbolic 
labeling for easy system 


designer reference 
-Speech 
Transaction File data base 


manager facilitates Speech 
Transaction File changes 


The Speech Transaction Development 
Set, iSB~ 
570, provides an easy-to-use package for speech transaction 
evaluation, 
design simulation 
and application 
development. 
Along with Intel's Speech Design Workshop, the 
Speech Transaction Development 
Set becomes the starter kit that will move you into the forefront of speech I/O 
systems. Using the demo program supplied, you are quickly introduced 
to the important 
attributes 
of speech. 
Using the Intellec® Microcomputer 
Development 
System and writing/modifying 
software 
based on examples 
provided, 
you can quickly 
simulate 
your application 
without 
hardware 
development. 
And finally, with 
the 
Speech 
Transaction 
Generator, 
your 
speech 
transaction 
structure, 
definition, 
transaction 
file coding 
and 
mangement 
become a well-defined 
automated 
task. 


intel 


The iSSC® 570 Speech Transaction Development 
Set 
has been designed to meet your speech I/O needs as 
your 
level of involvement 
with 
speech 
I/O system 
grows. 
The Speech 
Transaction 
Development 
Set 
serves 
three 
very 
important 
functions. 
The three 
functions 
are: 
1) Technology 
Evaluation 
and 


Demonstration, 
2) Application 
Simulation 
of Speech 
I/O, and 3) Design and Development 
of Speech Trans- 
action 
Software. 
These 
three 
functions 
are dis- 
cussed below. 


Technology 
Evaluation 
and 
Demonstration 
- 
A 
complete 
demo package is provided for you to dem- 
onstrate the capabilities 
of speech I/O. This package 
allows you to evaluate the speech technology 
with- 
out investing 
engineering 
design and development 
time. It IS easy to use. Major attributes 
of a speech I/O 
system are highlighted 
and fully documented. 
The 
host system 
for the demonstration 
is the Intellec~ 


Microcomputer 
Development 
System. 


Application 
Simulation 
of Speech I/O-The 
Speech 


Transaction 
Development 
Set provides 
the 
neces- 
sary tools 
and program 
examples 
for you to easily 
simulate your speech I/O system using the Intellec~ 
Microcomputer 
Development 
System 
as the 
host. 


With the iSSC® 570 and the Intellec~ Microcomputer 
Development 
System, you can now design a speech 


I/O system for your application 
and see how it per- 
forms. Your speech transaction 
structure 
can be de- 
veloped 
and checked 
out without 
doing 
hardware 


and software integration with the rest of your system. 


Design and Development 
of Speech Transactions - 


The Speech Transaction Generator which is provided 
as part of the Speech Transaction 
Development 
Set 


facilitates 
the design 
and development 
of speech 


transactions. 
The Speech Transaction 
Generator 
is 


an 
interactive 
software 
development 
tool 
that 


generates 
the Speech 
Transaction 
File (STF) that 


configures 
your 
speech 
I/O system. 
The 
Speech 


Transaction 
Generator checks for inconsistencies 
or 


incomplete 
transactions. 
The 
generated 
code 
is 


guaranteed 
to be fully compatible 
with the Speech 


Transaction 
Soard. 
The 
Speech 
Transaction 


Generator 
will 
not only shorten 
your development 


time, but will also facilitate 
a well human-engineered 


speech I/O interface. 


The Speech Transaction 
Generator 
is implemented 


in two parts. The first part is the processing 
element 


of the STG and resides on EPROM in an STS environ- 
ment. The second part is the data base manager for 
the STG and resides as an executable file under ISIS. 
The STG allows a system designer (with appropriate 
knowledge 
of transaction, 
fields, 
vocabulary 
and 
synthesis) to specify a STF easily. The STG maintains 
a set of files on the IntelieciPO system as the data base. 
In this 
manner, the STG is the customization 
tool 


used by the 
speech 
system 
designers 
to 
prepare 
application-unique 
speech transactions 
that will exe- 
cute on the STS under the supervision 
of the Speech 
Transaction Manager (STM). The STG also allows the 
system designer 
to dump portions 
of this data base 
in an ASCII-text format to a file. This ASCII-text file is 
useful 
for transporting 
data base entries 
between 
the 
STG 
implemented 
on 
other 
than 
an 
ISIS 
environment. 


The things 
that a system designer 
can manipulate 
with the STG are termed 
"objects." 
Objects 
can be 


catagorized 
into 
structures 
and 
non-structures. 


Structures 
are generally 
a string 
of characters 
or a 
list of tags. Objects 
are classified 
as follows: 


STRUCTURES 
1. Transaction 
2. Fields 
3. Vocabulary 
4. Synthesis 


NON-STRUCTURES 
1. Group (list of vocabulary 
tags) 


2. Strings 
(list of ASCII or non-ASCII characters) 


Brief Description of Commands 


UTILITY 
COMMANDS 
HELP-Provides 
information 
about the objects 


EXIT-Close 
data base and exit STG 


PREfix-Specify 
prefix 
character 
for 
DEFine 
or 
MODify commands 


DEFINE 
TRANSACTION: 
1. VocabUlary tag to enable this transaction? 
2. Training group? 
3. Starting 
field? 


4. Host buffer strategy? 
5. Verification 
actions? 


6. Special reject actions? 
7. Special illegal function 
action? 


DEFINE 
FIELD: 
1. Prompt? 
2. Help message? 
3. Prefix for host message? 
4. Suffix for host message? 
5. Special functions 
enable? 
6. Valid sources? 
7. Multiple 
utterance 
path? 
If yes, 
a) Vocabulary words? 
b) Next field? 
c) 
Maximum 
number of utterances? 
d) Fixed or variable? 
8. Vocabulary words? 
9. Next field? 


DEFINE 
VOCABULARY: 
1. Name? 
2. Visual verify? 
3. Audio verify? 
4. Host message? 
5. Visual train? 
6. Audio train? 
7. Special functions? 


DEFINE 
SYNTHESIS: 
1. Function? 
2. Duration? 
3. Delay? 


DELete 
Removes objects from the data base. 


MODify 
Modifies objects already entered into the data base 
with the DEFine command. 


VALidate 
Sequences through 
each of the transactions 
speci- 
fied and validates them for completeness 
and proper 
definition. 


GENerate 
Takes the result of a successful 
validate 
command 
and produces a memory image of the STF The STF 
can now be executed. 


INTERROGATION 
COMMANDS 


DISplays 
Displays the contents of the objects 


liSts 
lists 
the directory 
of the objects 


FILE INTERFACE 
COMMANDS 


DUMp 
Passes results of current validation 
and outputs 
it to 


the host in a .DMP file. 


USE 
Takes command 
input from the specified 
file 


lntellec' 
Microcomputer 
Development 
System 


(Model 800, Series II, and Series III with 64K byte of 
RAM). 


SUPPLIED 
EQUIPMENT 


iSBC' 
576-Speech 
Transaction Board with Speech 
Transaction 
Manager Firmware. 


-Speech 
Transaction Generator software 


and firmware. 


-Speech 
1/0 Demo Software. 


-iSBC$ 
575 Operator Control Unit. 


-Shure 
SM-10A Microphone. 


-Speech 
Transaction Design Manual. 


OPTIONAL 
EQUIPMENT 
iSBX'-351-RS232 
Multimodule 


iSBC -342-EPROM 
expansion 
module 


-SBX 
synthesizers 


inter 


iSBC® 576 
SPEECH TRANSACTION 
BOARD 


• 
Up to 200 recognition words or phrases 


• Automatic ASR and ESS handling 


• On-board Speech Transaction Manager 


• On-board diagnostic 


• Multibus or serial host interface 


The iSB~ 
576 Speech Transaction 
Board is the heart of a speech I/O system. Beside providing 
Automatic 


Speech Recognition 
(ASR) capabilities, 
a ROM-resident 
Speech Transaction Manager (STM) is included on the 


board. 
This provides 
a flexibile 
operating 
structure 
for the system designer 
with 
a fully 
buffered 
speech- 


generated input-transaction 
handling capability. 
Flexibility 
has been designed into the STM to allow integration 


into existing 
applications 
without 
a major rewrite/redesign 
of host application 
software 
and hardware. The 


Speech 
Transaction 
Manager 
accommodates 
a Speech 
Transaction 
File which 
configures 
the 
iSB~ 
576 


Speech Transaction Board for each application. 
Also included on the board are three selectable audio feedback 


tones, visual feedback/control 
via a CRT terminal 
or printer, and an optional 
Electronic 
Speech Synthesis (ESS) 


capability. 


Figure 
6 shows 
the 
functional 
structure 
of the 


Speech Transaction 
Board. 


Input Signal Conditioning-Microphone 
input signal 
is amplified 
and low-pass filtered. 
The conditioned 


signal is then digitized 
and passed through 
16 band- 
pass digital 
filters 
implemented 
by 2920/21 analog 


signal 
processors. 
The 2920/21s are synchronized 


and are operating 
in parallel. 
The bandpass 
filter 


information 
is then assembled by an 8048 microcom- 


puter for algorithm 
processing 
by an 8086 processor. 
System-to-system 
portability 
is guaranteed 
by the 


usage of digital 
signal processing 
techniques. 


ASR-Automatic 
Speech 
Recognition 
is accom- 


plished 
by the 8086 processor 
in conjunction 
with 
two 2920/21 digital 
signal 
processors 
and an 8048 


microcomputer. 
ASR handling 
is done 
completely 


under 
the 
control 
of 
the 
Speech 
Transaction 


Manager. This task is transparent 
to the system de- 
signers. 
Automatic 
statistics 
are also 
provided 
to 


track system performance. 


Tone Generator-3 
audio tones are available for use 


as a prompt. 
The tones are generated 
within 
a 2920 


analog 
signal 
processor. 
The tone 
generator 
also 


generates 
test 
patterns 
for 
use by the diagnostic 


section. 


Diagnostic-Under 
the control 
of the Speech Trans- 


action 
Manager, 
a diagnostic 
check 
of the speech 


VISUAL 
ANDm~g:~~• 
INPUT 


recognition 
hardware 
and 
software 
can 
be per- 


formed. System integrity 
is automatically 
determined 


to insure repeatable 
performance. 


Output 
Signal Conditioning-Output 
amplifiers 
are 


provided 
to drive 
a speaker 
for the 
audio 
tones. 


Volume can be varied by a potentiometer. 


Terminal 
Driver-Under 
the control 
of the Speech 


Transaction 
Manager, a CRT terminal/keyboard 
can 


be connected 
directly 
to the 
Speech 
Transaction 


Board. The terminal 
can be used for visual feedback 


as well as data entry/control. 
The interface 
is RS232 


compatible. 


Operator Control-Two 
LED lights to indicate recog- 


nition 
status 
and an operator 
attention 
button 
are 


provided. These functions 
are programmable 
under 


the control 
of the Speech Transaction 
Manager. 


Operator 
Reference 
Patterns-Speech 
patterns 
for 
recognition 
are normally contained 
in RAM. The pat- 


terns are downloaded 
from the host processor under 
the control 
of the Speech Transaction 
Manager. The 


operator 
reference 
patterns 
are also generated 
un- 


der the control 
of the Speech Transaction 
Manager. 


Speech Transaction 
Manager-The 
Speech Transac- 
tion Manager is the heart of the Speech Transaction 
Board. The Speech Transaction 
Manager controls 
all 


of the functions 
within 
the board. This firmware 
is 


contained 
in 27128 EPROMs and is RMXqj)-88(Real- 
Time Multi-Tasking 
Executive) 
based. Processing 
is 


provided 
by the 8086 processor. 


Speech Transaction 
File-The 
Speech Transaction 
File determines 
the configuration 
of the board for 
each application. 
The Speech Transaction 
Manager 
executes this file which is normally downloaded 
from 
the host and-stored 
in RAM. The file can also be 
stored 
in ROM/EPROM on the Speech Transaction 
Board itself. These files are generated by the Speech 
Transaction 
Generator. 


Multibusqj) Interface-A 
slave multibus<!>interface 
is 
implemented 
On the multi bus the Speech Transac- 


tion Board looks like a data port. 


iSBX@Interface-One 
SBX® interface 
has been im- 


plemented 
This 
interface 
is controlled 
by the 
Speech Transaction 
Manager. Interface 
with a non- 
Multibus® host can be implemented 
via this channel. 


The operation 
of the Speech Transaction 
Board 
is 
determined 
by the Speech Transaction Manager. The 


Speech 
Transaction 
Manager 
has several 
specific 


modes of operation 
as described 
below. 


Speech Transaction 
Processing 
Mode-This 
mode 
enables 
the operator 
to enter 
by speech, 
or key- 


board. a transaction 
message to a multibus or serial 
host. 


File Mode-This 
mode supports file loading from the 
host through 
the multibus 
or serial interface. 
Load· 


ing and saving of operator 
reference 
patterns 
are 
also handled here. 


Diagnostic 
Mode-This 
mode 
tests the 
hardware 
The diagnostics 
will test the 2920/8048 interface and 
the 8048/8086 interface. 


Terminal Mode-This 
mode provides for direct com- 
munication 
between the host and the Speech Trans- 


action 
Board 
terminal. 
All 
response 
from 
the 
operator (through 
the terminal) 
is passed directly 
to 
the host. ALL host messages are passed directly 
to 
the terminal. 


Parameter 
Mode-This 
mode lets the user define a 
limited 
set of configuration 
information 
and to set 
various other system parameters. 


Evaluation 
Mode-This 
mode lets the user evaluate 
the recognition 
performance 
of an STF vocabulary or 
a vocabulary 
entered from the STB terminal. 
Use of 
this mode will facilitate 
evaluation 
of training 
strate- 


gies, vocabulary 
choices and parameter 
settings. 
In 
this mode statistics and automatic 
scoring 
of results 
are all standard 
features. 


STP-enter 
speech transaction 
processing 
mode 


FIL-enter 
file mode 
DIA-enter 
diagnostic 
mode 


TER-enter 
terminal 
mode 


PAR-enter 
parameter mode 
MaN-enter 
monitor mode 


EVA-enter 
evaluation 
mode 
HELP-list 
help commands 


EXIT-exit 
current mode 
INI-initiallze 
statistics 


RES-restores 
system status 


Speech"Transaction Processing 
Mode Function 


Forward 
Backup 
Correction 
Replace 
Forward Field 
Backup Field 


Erase Field 
Continue 
Beginning 
Cancel 
Finish 


Help-operator 
assistance at each field 


Display-current 
transaction buffer 
Next-go 
to next field 
Detach-put 
terminal in "Terminal Mode" 
Attach-get 
terminal out of "Terminal Mode" 
Exit-exit 
STP mode 
Up-raise 
rejection threshold 
Down-lower 
rejection threshold 
Relax-put 
system in not-ready state 


Ready-first 
of two utterances to exit not-ready 


state 
Attention-second 
of two utterances to exit not- 
ready state 
Enable Transaction "N"-initiate 
transaction 


Macro-performs 
a series of commands 


automatically in any mode 


Operator Speech Pattern 
Maintenance Functions 


Test Group 
Test All 
Retrain 
Retrain Group 
Retrain All 
Delete 
Delete All 


Train 
Train Group 
Train All 
Update 
Update Group 
Update All 
Test 


LST-load 
Speech Transaction File 


SST-save 
speech transaction file 
LRP-Ioad 
operator speech patterns 


SRP-save 
operator speech patterns 


CRP-c1ear 
operator speech pattern RAM area 


HELp-list 
help commands 
CST~clear 
speech transaction 


EXit-exit 
current mode 
LDI-Ioad 
dictionary 
SDI-save 
dictionary 


FET-front 
end test 
EXit-exit 
mode 
HELp-list 
help commands 


BLO-block 
size of transfer 


, CHS-communication 
header 
CON-display 
all configuration 
parameters 


DIS-discrimination 
level 
DRE-small 
delta rejection 
EST-display 
extended statistics 
HOS-specifies 
host and characteristics 


HTE-host 
terminator string 
HTO-host 
time-out 
INS-initialize 
statistics 
MTP-minimum 
training passes 
RPT-operator 
reference pattern names 
SHC-serial 
host baud rate 
STA-displays 
statistics 
STF-STF 
name 
STR-ROM 
STF name 
TST-STB 
terminal status 
WRD-word 
gap and word length 
FEG-front-end 
gain 
HELp-list 
help commands 
EXit-exit 
current mode 


DEF-define 
MYO-modify 
vocabulary 
RYO-remove 
vocabulary 
RRP-remove 
reference pattern 
RET-retrain 
LIS-list 
vocabulary 
TRAin-train 
UPDate-update 
TESt-test 
RECogn ition-recogn 
ition 
STA-statistics 
COR-cross 
correlation 
INS-initialize 
statistics 
HELp-list 
help commands 
EXit-exit 
current mode 


Host Processor-any 
iSBCiIPMultibusiIP computer 


-any 
RS232 serial host interface 


Audio Input-475fl 
input impedence 


-SO 
m.v. p-p max. 


-differential 
or single-ended 


iSBG'!' 576 Speech Transaction 
Board with Speech 


Transaction 
Manager Firmware 


iSBXiIP-351 
iSBX<!Il-342 


RS232 Multimodule 
EPROM expansion 
SBX synthesizer 
Operator Control 
Unit 


Recognition 
vocabulary-200 
words or phrases 


Utterance duration-user 
selectable> 
100 msec., 
minimum 
-user 
selectable < 2 sec. 
maximum 


Rejection Threshold-user 
selectable 


Word gap-user 
selectable> 
50 msec., minimum 


-user 
selectable < 250 msec., 


maximum 
Recognition 
Accuracy (50 state names)-99+% 
Response Time (for vocabulary 
up to 200 words 


with maximum 
node length 50 


words) - 
< 500 msec. 


Width-6.75 
in. (17.15 cm) 
Height-0.5 
in. (1. 'Z1 cm) 
Length-12.0 
in. (30.48 cm) 


Shipping 
weight- 
TBD 
Mounting-occupies 
one slot of iSBCiIPsystem 


chasis in cardcage/backplane. 
With 


iSBXiIPMultimodule™ 
board mounted, 


vertical 
height increases to 1.13 in. 
(2.87 cm) 


Power Requirements 
+5V DC@3A 
+10V DC @ TBD 
·Multimodule™ 
-12V 
DC@ 0.02 A ·Multimodule™ 


+12V DC@ 0.5 A 


Temperature-O 
to 55°C (operating): 
-55°C 
to 85°C 


(non-operating) 


Humidity-up 
to 90% relative humidity 
without 


condensation 
(operating); 
all conditions 


without 
condensation 
or frost (non- 


operating) 


iSBC® 577 


SPEECH TRANSACTION 
RECOGNITION 
CHIP SET 


• Fully compatible with iSaC 570, 576- 


generated software 


The iSB~ 
577 Speech Recognition 
Chip Set is a solution 
for your high-volume/maximum 
value-added 
speech 
I/O solution. 
The Chip Set contains 
the Intel-developed 
proprietary 
components 
from the iSB~ 
576 Speech 
Transaction 
Board. With these components 
you can build the equivalent 
of the Speech Transaction 
Board into 
your own system. The Chip Set contains 
the digital 
front-end 
processors, 
a preprogrammed 
8048 interface 
processor, the Speech Transaction 
Manager 
Firmware 
on 27128 EPROMs, and the 8086 microprocessor. 


2-Preprogrammed 
2920/21s 
(Digital 
Front-end 


Processor) 
4-Preprogrammed 
27128 
(Speech 
Transaction 


Manager) 
1-Preprogrammed 
8048 (Interface 
Processor) 


1-8086 


Speech Transaction 
Recognition 


Chip Set 


inter 


iSBC™ 550 


ETHERNET™ COMMUNICATIONS 
CONTROLLER 


• Meets the version 
1.0 tri-corporate 
Ethernet 
specification 


• Ethernet 
data link layer support 
• Data encapsulation 
• Framing 
and packet 
control 


• Buffer 
management 


• Ethernet 
physical 
link layer support 


• Serial/de serialization 
• 10 Mbits 
per second 
data rate 
• CRC generation/check 
• Carrier-sense 
multiple-access 
with 
collision 
detection 
(CSMA/CD) 
• Transceiver 
interface 
compatibility 


• Easy-to-use 
MULTIBUS@ inter- 
processor 
protocol 
supported 
in 


firmware 


• Power-up confidence 
test assures 
integrity 
of on·board 
memory 
and 


programmable 
LSI 


• Traffic, 
errors and collision 


information 
maintained 
for network 


management 


• Excellent 
foundation 
for Ethernet 


local area end-to-end 
network 


The iSBC 550 Ethernet 
Communications 
Controller 
meets 
the tri-corporate 
(DEC, Xerox, 
Intel) specifi- 
cation 
for Ethernet 
local area networks. 
All the functions 
of the Ethernet data link layer and physical 
link 
layer are provided 
on two 6.75 x 12" circuits 
boards and associated 
firmware. 
The MULTIBUS 
compatible 


controller 
can be utilized 
as the foundation 
for a single 
board computer 
(iSBC)-based 
Ethernet 
local area 


network 
or as a prototype 
for Intel<!l 8085, iAPX™ 88, or iAPX 86 component-based 
Ethernet 
applications. 


The iSBC 550 controller's 
firmware 
(supplying 
the 
Ethernet 
and system 
interface) 
has an easy-to-use 


MULTIBUS 
Interprocessor 
Protocol 
(MIP) facility, 
which 
is readily 
accessed 
from 
another 
iSBC Board 
using a custom 
run-time 
software 
system or Intel's 
iRMX™ 80/88/86 Real-Time Executive 
software 
and the 
iMMX™ 
800 (MUL TIBUS 
Message 
Exchange) 
software 
package. 
The 
Ethernet 
data 
link 
functions 
are 


divided 
between 
the processor 
board which 
provides 
the data link layer's software 
to control 
the data en- 
capsulation 
and the link management, 
and the serialfdeserialization 
(SerDes) board which 
provides 
the 
10-MBit per second 
serial interface 
to the Ethernet 
transceiver. 


The follOWIng 
are trademarks 
at Intel 
Corporation 
and may be used 
10 descnbe 
Intel 
products: 
CREDIT, Index, 
Inslte, 
loleltec. 
library 
Manager. 
Megachassis. 
Mlcromap, 


MUlTIBUS. 
PROMPT, 
UP!. p.Scope, Promware. 
MeS. ICE. IRMX. ,sec, 
,sex, 
MUL TIMODULE, 
les. 
IAPX and IMMX, 
Intel Corporallon 
assumes 
no responsibility 
for the use of any 


Circuitry 
other than circuitry 
embodied 
In an Intel product. 
No other circuit 
patent 
licenses 
are implied 


The iSSC 550 Ethernet 
Communications 
Control- 
ler is a two-board 
MULTISUS-compatible 
set that 
offers 
high-speed 
Ethernet-compatible 
data trans- 


fer between 
digital 
devices 
operating 
at a 10-Mbit 
per s~c data rate. The iSSC 550 controller 
can ef- 
fectively 
support 
the needs of local area network 
applications, 
such 
as 
office 
automation, 
dis- 
tributed 
data processing, 
factory 
data collection, 


research 
data collection, 
intelligent 
terminal 
and 
other 
EDP-related 
products. 


Ethernet 
Specification 


The Ethernet 
network 
is a local area network 
con- 
cept that is jointly 
being supported 
by Intel Corpo- 
ration, 
Digital 
Equipment 
Corporation, 
and Xerox 
Corporation. 
The network 
is designed 
to link sys- 
tems 
over a distance 
of up to 2500 meters 
using 
an available 
50-ohm 
coaxial 
cable. 
Several 
hun- 
dred 
stations 
may 
be connected 
to 
the 
cable 
which 
supports 
a data rate of 10 Megabits 
per sec- 
ond. The data 
is encapsulated 
in a packet 
mes- 


sage 
format. 
The 
data 
signal 
is 
a 
base-band, 


Manchester-encoded 
type that is self-synchroniz- 
ing. 


The jointly 
developed 
Ethernet specification, 
"The 
Ethernet, 
A Local 
Area Network 
Data Link 
Layer 
and 
Physical 
Link 
Layer 
Specification, 
Version 
1.0, September 
30, 1980", 
precisely 
defines 
the 
two lower 
layers of a local area network 
architec- 


ture where the system 
is a series of independent 


layers. The lowest 
layer, the physical 
link layer, is 


concerned 
with 
coaxial 
cable 
interface. 
The data 


link 
layer supports 
the peer protocol's 
statistical 


contention 
resolution 
(CSMAlCD) 
and link 
man- 


agement 
functions. 
All additional 
network 
layers 
are defined 
by the user during 
the implementation 
of the application-specific 
layers. 


Ethernet 
Data Link Layer Support 


The iSSC 550 processor 
board 
provides 
the data 
link layer's software 
to control 
the data encapsula- 
tion 
and the 
link 
management, 
including 
frame 
delimitation, 
address 
handling, 
error 
detection, 


and collision 
handling. 
After 
the 
iSSC 
550 pro- 
cessor board is initialized 
upon system 
start-up 
or 
reset, the data link firmware 
is ready to service the 


local 
area network 
commands. 
An example 
of a 
command 
structure 
sent 
the 
iSSC 
controller 
to 


receive 
a packet 
of data from the Ethernet 
link is 
shown 
in Figure 
1. The message 
passed 
via the 
MIP 
(MUL TISUS 
Interprocessor 
'Protocol) 
inter- 


face is composed 
of two parts, the iSSC 550 con- 
troller 
information 
(including 
the 
command 
and 


" 
associated 
data), and the required 
Ethernet 
infor- 


mation. 


iSBC 
550 { RESERVED 
DATA 
CONTROLLER 
COMMAND· 


INFORMATION 
RESERVED 
DATA 


{ 


DESTINATION 
ETHERNET 
SOURCE 
INFORMATION 
TYPE 
DATA 


(14 bytes) 
(1 byte) 
(7 bytes) 


(6 bytes) 
(6 bytes) 
(2 bytes) 
(46-1500 
bytes) 


Figure 
1. Data Link for SUPPLYBUF 
Command 


Format 


Shown 
in Table 1 are eight 
external 
Ethernet 
con- 


troller 
commands 
available 
to a user's application 


via the MIP interface. 
The commands 
manage the 


Ethernet 
multicast 
address 
recognition, 
message 


type 
connection, 
message 
flow, 
and overall 
net- 


work statistics. 


Command 
Function 


CONNECT 
Indicates 
the 
data 
link 
message 


TYPE to be connected 
to user pro- 


gram. 


DISCONNECT 
Disconnects 
the data link TYPEfrom 


the user's application. 


ADDMCID 
Adds a multicast 
10 for recognition. 


DELETEMCID 
Delete the specified multicast 
10. 


TRANSMIT 
Transmit a data packet to the Ether- 
net link. 


SUPPLYBUF 
Supplies 
a buffer for packet recep- 


tion from the Ethernet link ("receive" 
function). 


READ 
Read the statistical 
variables milin- 


tained by data link layer. 


READC 
Read and clear the statistical 
vari- 


ables. 


Ethernet 
Physical 
Link Layer Support 


The 
Serialization/Deserialization 
(SerDes) 
board 
provides 
the required 
electrical 
characteristics 
of 
the physical 
link layer of the Ethernet architecture 


for 
a transceiver 
interface. 
The transceiver 
is a 


device 
physically 
attached 
to 
the 
coax 
cable 


which 
does 
signal 
conditioning 
for transmitting 
and receiving. 


Many 
major 
functions 
are 
controlled 
by 
the 


SerDes 
board. These 
functions 
include 
serializa- 


tion/deserialization, 
packet 
framing, 
Manchester 


enc'oding/decoding, 
transmit 
data 
flow 
control, 


receive data flow control, 
destination 
address 
de- 
coding 
for received 
message, CRC generation 
and 


checking, 
and 
diagnostics 
for 
CRC error, 
loop- 


back, 
transmit 
timeout, 
and 
CSMAlCD 
(Carrier- 
Sense Multiple-Access 
with Collision-Detection). 


Easy·To·Use Interface 


One of the iSBC 550 controller 
boards 
is an iAPX 


88-based 
processor 
board 
which 
has 
firmware 


support 
for the user's 
application 
interface. 
The 


programmatic 
interface 
utilizes 
the 
MULTIBUS 


Interprocessor 
Protocol 
(MIP) interface 
to the pro· 


cessor board. This interface 
is concerned 
with the 


message-passing 
protocol 
between 
multiple- 
processors. 
The iMMX 
800 (MULTI BUS Message 


Exchange) 
software 
supports 
the 
MIP interface 


and offers 
a convenient 
quick-start 
method 
for 


users of Intel's 
iRMX 80, iRMX 88 executives 
and 


iRMX 86 operating 
system 
products 
for an Ether- 
net-based 
application. 


An effective 
diagnostic 
function 
is implemented 
in firmware 
on the processor 
board. This function 


is 
invoked 
at 
system 
initialization 
during 
both 


power-up 
and system 
reset time. These functions 


include: 
packet 
CRC checking, 
memory 
test, con- 
troller 
loopback, 
and other 
error tests. 
The tests 


provide a fundamental 
level of controller 
integrity. 


Statistics 
maintained 
by the data link firmware 
in- 
clude 
packet 
traffic 
counts, 
collision 
information 


isec 801:'30 I iRMX80 


.6105 


86J12A 
.3125 


88140 


and error 
totals. 
This 
information 
can 
be effec- 


tively 
utilized 
by the user's 
application 
to under- 


stand the network's 
operation. 


End·To·End Networking Foundation 


The iSBC 550 controller 
provides 
the foundation 


data 
link 
layer 
and the 
physical 
link 
layer 
for a 
local 
area 
network 
architecture. 
Typically, 
the 


higher 
levels 
are 
user-defined 
and 
include 
the 


transport 
and 
the 
session 
control 
layers. 
The 


transport 
control 
layer is concerned 
with the end- 


to-end 
communications 
and the 
virtual 
channel 


connection 
via a port-to-port 
address. The session 


control 
layer provides 
the process-to-process 
con- 


trol function 
which 
includes 
symbolic 
name bind- 
ing and the establishment 
of the virtual 
connec- 


tion via the transport 
control 
layer. In addition, 
the 


session 
control 
provides 
the specific 
error and reo 
covery control 
responsible 
for message 
delivery. 


The higher 
levels of the local area network 
archi- 


tecture 
(see Figure 2) which 
use the data link layer 
are outside 
of the Ethernet 
standard, 
but can be 


implemented 
quickly 
on companion 
iSBC boards 


(e.g., iSBC 80/24, iSBC 88/25, iSBC 86/12A) running 
under 
the 
iRMX 80/88/86 
Real-Time 
Multitasking 


Executives, 
respectively, 
and 
associated 
iMMX 


MULTI BUS Message 
Exchange 
(iMMX 
800) soft- 


ware. 
Special 
iSBC 
550 device 
driver 
software 


compatible 
with the iRMX 86 and iRMX 88 file sys- 
tems 
is provided 
in the iMMX 800 package. 


COAX 
~ 


-CABLE 
~ 


TRANSCEIVER~ 


TRANSCEIVER 
CABLE I 
so 
melers 
MAX 
----+- 


(LESS 
SEROES 
CABLE) 


SERDES 
TO r 
TRANSCEIVERCABlE----.... 


0.55 meter 
ENCODE AND 


DECODE 
FUNCTION 
CSMA,CD 


10 
Mbil'sec 


LINK 
MANAGEMENT 
FUNCTION 


DATA 
ENCAPSULATION 


FUNCTION 


Memory Addressing Capability 


MULTIBUS 
System 
Bus - 
(OOOOO-EFFFF) 


One 
Ethernet 
electric~lIy·compatible 
transceiver 
line on the SerDes board. 


Interface Specifications 


MULTIBUS 
System 
Bus - 
All signals 
TTL com· 
patible. 


Transceiver 
- 
All signals 
Ethernet 
specifications 
transceiver 
compatible. 


Serial Communications 
Characteristics 


Bit 
Serial 
Frame 
- 
Provides 
64-bit 
preamble, 


48-bit destination 
address, 
48-bit source 
address, 


16-bit 
type, 
46-1500 
bytes 
for data, 
and a frame 
check 
sequence 
of 32 bits. 


Ethernet 
Network Specifications 
Supported 


Coax Cable 
Length 
- 
500-meter 
max. 


Transceiver 
Cable 
Length 
- 
50-meter 
max. 


Number 
of Stations 
- 
100 max. 


Baud Rate - 
10-Mbit/sec 


System Clock 


5.00 MHz, ±0.1% 


Physical Characteristics 
(Both Boards) 


Width 
- 
12.00 in. (30.48 em) (each board) 


Height 
- 
6.75 in. (17.15 em) (each board) 


Depth 
- 
0.5 in. (1.27 em) (each board) 


Weight - 
3.5 Ib (1.6 kg) (both boards) 


SerDes to Transceiver Cable 


Length 
- 
0.55 meter 
(22 in.). Four 
pair twisted- 


wire cable with SerDes connector 
and transceiver 


interface 
connector. 


Power requirements 
for both boards 
+ 5 VDC @ 9.0A max. 
+ 12 VDC @ 0.5A max. 


Environmental Characteristics 


Operating 
Temperature 
- 
O°C to 55°C 


Relative 
Humidity 
- 
To 90% (without 
condensa· 


tion) 


Interface 
Pins 
Centers 
Mating 
Connectors 
(qty) 
(in.) 


MULTIBUS 
86 
0.156 
Viking 
2KH43/9AMK12 
System 


SerDes 
AMP 
87631-5 
Housing 
Edge 
10 
0.1 
Connector 
AMP 
87195-9 
Pins 


Transceiver 
15 
0.1 
Cinch 
Type 
DA 51220-1 


Reference Manuals 


121746 
- 
iSBC 
550 
Ethernet 
Communic"ations 
Controller 
Hardware 
Reference 
Manual (NOT SUP- 


PLIED) 


121769 - 
The Ethernet 
Communications 
Control- 


ler 
Programmer's 
Reference 
Manual 
(NOT 
SUP- 


PLIED) 


Manuals 
may be ordered 
from any Intel sales rep- 


resentative, 
distributor 
office 
or from 
Intel litera- 


ture 
Department, 
3065 
Bowers 
Avenue, 
Santa 


Clara, CA 95051. 


Part Number 


SBC 550 
Description 


Ethernet 
Communications 
Con- 
troller 
for 10 Mbitlsec 
coaxial 


transmission. 
Includes 
Ethernet 
data link control 
software 
and 


cable 
to transceiver. 


iSBC 544 
INTElliGENT 
COMMUNICATIONS 
CONTROllER 


• iSBC Communications 
Controller acting 
as a single board communications 
computer or an intelligent slave for 
communications 
expansion 


• On-board dedicated 808SA Micro- 
processor providing communications 
control and buffer management for 
four programmable synchronousl 
asynchronous channels 


• Sockets for up to 8K bytes of EPROM 


• 16K bytes of dual port dynamic readl 
write memory with on-board refresh 


• Extended MUL TIBUS addressing 
permits iSBC 544 board partitioning 
into 16K-byte segments in a 1-megabyte 
address space 


• Ten programmable parallel I/O lines 


compatible with Bell 801 Automatic 
Calling Unit 


• Twelve levels of programmable 


interrupt control 


• Individual software programmable baud 
rate generation for each serial I/O 
channel 


• Three independent programmable 


interval timer/counters 


• Interface control for auto answer and 


auto originate modem 


The iSBC 544 Intelligent Communications Controller is a member of Intel's family of single-board computers, memory, 
110, and peripheral controller boards. The iSBC 544 board is a complete communications 
controller on a single 


6.75x 12.00 inch printed circuit card. The on-board 8085A CPU may perform local communications 
processing by 


directly interfacing with on·board read/write memory, nonvolatile read only memory, four synchronous/asynchronous 
serial I/O ports, RS232/RS366compatible parallel I/O, programmable timers, and programmable interrupts. 


Intelligent 
Communications 
Controller 


Two 
Mode 
Operation 
- 
The iSBC 544 board is capable 
of operating in one of two modes: 1) as a single board 
communications 
computer with all computer and com- 
munications interface hardware on a single board; 2) as 
an "intelligent 
bus slave" that can perform communica- 


tions related tasks as a peripheral processor to one or 
more bus masters. The iSBC 544 may be configured to 
operate as a stand-alone single board communications 
computer with all MPU, memory and I/O elements on a 
single board. In this mode of operation, the iSBC 544 
may also interface 
with 
expansion memory and I/O 


boards (but no additional bus masters). The iSBC 544 
performs as an intelligent 
slave to the bus master by 


performing all communications related tasks. Complete 
synchronous 
and 
asynchronous 
I/O 
and 
data 
management are controlled by the on-board 8085A CPU 


can be managed entirely 
on-board, freeing 
the bus 


master to perform other system functions. 


Architecture 
- 
The iSBC 544 board is functionally parti- 


tioned into three major sections: I/O, central computer, 
and shared dual port RAM memory (Figure 1). The I/O 
hardware is centered around the four Intel 8251A USART 
devices providing fully programmable serial interfacing. 
Included here as well is a 10-bit parallel interface com- 
patible with the Bell 801 automatic calling unit, or equiv- 
alent. The I/O is under full control of the on-board CPU 
and is protected from access by system bus masters. 
The second major segment of the intelligent communi- 
cations controller is a central computer, with an 8085A 
CPU providing 
powerful 
processing 
capability. 
The 


8085A together with on-board EPROM / ROM, static 
RAM, programmable 
timers/counters, 
and 
program- 
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mabie interrupt control provide the intelligence to man- 
age sophisticated communications operations on-board 
the iSBC 544 board. The timer/counters 
and interrupt 
control are also common to the I/O area providing pro· 
grammable baud rates to the USARTs and prioritizing 
interrupts generated from the USARTs.The central com- 
puter functions are protected for access only by the on· 
board 8085A. Likewise, the on-board 8085A may not gain 
access to the system bus when being used as an in- 
telligent 
slave. When the iSBC 544 is used as a bus 
master, the on-board 8085A CPU controls 
complete 
system operation accessing on-board functions as well 
as memory and I/O expansion. The third major segment, 
dual port RAM memory, is the key link between the iSBC 
544 intelligent 
slave and bus masters managing the 
system functions. The dual port concept allows a com- 
mon block of dynamic memory to be accessed by the 
on·board 8085A CPU and off-board bus masters. The 
system program can, therefore, utilize the shared dual 
port RAM to pass command and status 
information 
between the bus masters and on-board CPU. In addition, 
the 
dual 
port 
concept 
permits 
blocks 
of 
data 
transmitted 
or received to accumulate in the on·board 
shared RAM, minimizing 
the 
need for a dedicated 
memory board. 


Serial I/O 
Four programmable communications 
interfaces using 
Intel's 
8251A Universal 
Synchronous/Asynchronous 
Receiver/Transmitter 
(USART) are contained 
on the 
board and controlled by the on-board CPU in combina- 
tion with the on-board interval timer/counter to provide 
all common communication 
frequencies. Each USART 
can be programmed by the system software to individu- 
ally select the desired asynchronous or synchronous 
serial 
data transmission 
technique 
(including 
IBM 
Bisync). The mode of operation (i.e., synchronous or 
asynchronous), data format, control character format, 
parity, and baud rate are all under program control. Each 
8251A provides full duplex, double-buffered, transmit 
and receive capability. Parity, overrun, and framing error 
detection 
are all incorporated 
in each USART. Each 
channel is fully buffered to provide a direct interface to 
RS232C compatible 
terminals, 
peripherals, 
or syn- 
chronous/asynchronous 
modems. 
Each channel 
of 
RS232C command lines, serial data lines, and signal 
ground lines are brought out to 26-pin edge connectors 
that mate with RS232Cflat or round cable. 


Parallel 
I/O Port 


The iSBC 544 provides a 10-bit parallel I/O interface con- 
trolled by an Intel 8155 Programmable Interface (PPI) 
chip. The parallel I/O port is directly compatible with an 
Automatic 
Calling Unit (ACU) such as the Bell Model 
801,or equivalent, and can also be used for auxiliary fun- 
ctions. All signals are RS232Ccompatible, and the inter- 
face cable signal assignments 
meet RS366 specifica- 
tions. For systems not requiring an ACU interface, the 
parallel 
I/O port can be used for any general purpose 
interface requiring RS232Ccompatibility. 


Central Processing Unit 


Intel's powerfUl 8-bit n-channel 8085A CPU, fabricated 
on a single LSI chip, is the central processor for the 
iSBC 544.The 8085A CPU is directly software compatible 
with the Intel 8080A CPU. The 8085A contains six 8-bit 
general purpose registers and an accumulator. The six 
general purpose registers may be addressed individually 
or in pairs, providing both single and double precision 
operators. The minimum instruction 
execution time is 
1.45microseconds. The 8085A CPU has a 16·bit program 
counter. An external stack, located within any portion of 
iSBC 544 read/write memory, may be used as a last·in/ 
first-out storage area for the contents of the program 
counter, flags, accumulator, and all of the six general 
purpose registers. A 16-bit stack pointer controls the ad- 
dressing of this external stack. This stack provides sub· 
routine nesting bounded only by memory size. 


EPROM/ROM 
Capacity 


Sockets for up to 8K bytes of nonvolatile read only memo 
ory are provided on the iSBC 544 board. Read only memo 
ory may be added in 2K·byte increments up to a max· 
imum of 4K bytes using Intel 2716 EPROMs or masked 
ROMs;or in 4K-byte increments up to 8K bytes maximum 
using Intel 2732 EPROMs. All on-board EPROM/ROM 
operations are performed at maximum processor speed. 


RAM Capacity 


The iSBC 544 contains 16K bytes of dynamic read/write 
memory using Intel 2117 RAMs. Power for the on-board 
RAM may be provided on an auxiliary power bus, and 
memory protect logic is included for RAM battery back· 
up requirements. The iSBC 544 contains a dual port con· 
troller, which provides dual port capability 
for the on· 
board RAM memory. RAM accesses may occur from 
either the on-board 8085A CPU or from another bus 
master, when used as an intelligent 
slave. Since on- 
board RAM accesses do not require the MULTIBUS, the 
bus is available for concurrent bus master use. Dynamic 
RAM refreSh is accomplished automatically by the iSBC 
544 for accesses originating from either the CPU or from 
the MULTIBUS. 


Addressing 
- 
On board RAM, as seen by the on-board 
8085A CPU, resides at address 8000wBFFFH. On-board 
RAM, as seen by an off-board CPU, may be placed on 
any 4K-byte address boundary. The iSBC 544 provides 
extended 
addressing 
jumpers 
to allow the on-board 
RAM to reside within a one megabyte address space 
when accessed via the MULTIBUS. In additon. jumper 
options are provided which allow the user to protect 8K· 
or 12K-bytes on-board RAM for use by the on-board 
8085 CPU only. This reserved RAM space is not access- 
ible via the MULTIBUS and does not occupy any system 
address space. 


Static RAM - 
The iSBC 544 board also has 256 bytes of 
static RAM located on the Intel 8155 PPI.This memory is 
only accessible to the on·board 8085ACPUand is located 
at address 7FOOH-7FFFH. 


Programmable Timers 


The iSBC 544 board provides seven fully programmable 
and independent 
interval timer/counters 
utilizing 
two 
Intel 8253 Programmable Interval Timers (PIT), and the 
Intel 8155. The two Intel 8253 PITs provide six independ- 
ent BCD or binary 16-bit interval timer/counters and the 
8155 provides one 14·bit binary timer/counter. 
Four of 


the PIT timers (BDGO·3) are dedicated to the USARTs 
providing fully independent programmable baud rates. 


Three General Use Timers - 
The fifth timer (BDG4)may 


be used as an auxiliary baud rate to any of the four 
USARTsor may alternatively be cascaded with timer six 
to provide extended interrupt 
intervals. The sixth PIT 


timer/counter (TINT1) can be used to generate interrupt 
intervals to the on-board 8085A. In addition to the timer/ 
counters on the 8253 PITs, the iSBC 544 has a 14·bit 
timer available on the 8155 PPI providing a third general 
use timer/counter 
(TINTO).This timer output is jumper 


selectable to the interrupt 
structure 
of the on·board 


8085ACPUto provide additional timer/counter capability. 


Timer Functions - 
In utilizing the iSBC 544 board, the 


systems designer simply configures, via software, each 
timer independently 
to meet systems 
requirements. 
Whenever a given baud rate or interrupt 
interval 
is 


needed, software 
commands 
to the programmable 


timers select the desired function. The on-board PITs 
together with the 8155 provide a total of seven timer/ 
counters and six operating modes. Mode 3 of the 8253 is 
the primary operating mode of the four dedicated USART 
baud rate generators. The timer/counters 
and useful 


modes of operation for the general use timer/counters 
are shown in Table 1. 


Interrupt Capability 


The iSBC 544 board provides interrupt service for up to 
21 interrupt sources. Any of the 21 sources may interrupt 
the intelligent controller, and all are brought through the 
interrupt logic to 12 intefrupt levels. Four interrupt levels 
are handled directly by the interrupt processing capa- 
bility of the 8085A CPU and eight levels are serviced 
from an Intel 8259A Programmable Interrupt Controller 
(PIC) routing an interrupt 
request output to the INTR 


input of the 8085A (see Table 2). 


Interrupt 
Sources - 
The 22 interrupt sources originate 


from both on-board communications functions and the 
Multibus. Two interrupts 
are routed from each of the 


four USARTs (8 interrupts 
total) to indicate that the 


transmitter and receiver are ready to move a data byte to 
or from the on·board CPU. The PIC is dedicated to 
accepting these 8 interrupts to optimize USART service 
request. One of eight interrupt request lines are jumper 
selectable for direct interface from a bus master via the 
system bus. Two auxiliary timers (TINTOfrom 8155 and 
TINT1 from 
8253) are jumper 
selectable 
to 
provide 


general 
purpose 
counterltimer 
interrupts. 
A jumper 


selectable Flag Interrupt is generated to allow any bus 
master to interrupt the iSBC 544 by writing into the base 
address of the shared dual port memory accessable to 
the system. The Flag Interrupt is then cleared by the 
iSBC 544 when the on·board processor reads the base 
address. This interrupt provides an interrupt link between 


Function 
Operation 
Counter 


Interrupt on 
When terminal count 
8253 


Terminal Count 
is reached, an inter· 
TINT1 


(Mode 0) 
rupt request is gener- 
ated. This function is 
useful for generation 
of real·time clocks. 


Rate Generator 
Divide by N counter. 
8253 


(Mode 2) 
The output will go low 
BDG4* 


for one input clock 
cycle and high for N·1 
input clock periods. 


Square·Wave 
Output will remain 
8253 


Rate Generator 
high until one·half the 
BDGO·4 


(Mode 3) 
TC has been com· 
TINT1 


pleted, and go low for 
the other half of the 
count. This is the pri· 
mary operating mode 
used for generating a 
Baud rate clocked to 
the USARTs. 


Software 
When the TC is loaded, 
8253 


Triggered 
the counter will begin. 
BDG4* 


Strobe 
On TC the output will 
TINT1 


(Mode 4) 
go low for one input 
clock period. 


Single Pulse 
Single pulse when TC 
8155 


reached. 
TINTO 


Repetitive' 
Repetitive single pulse 
8155 


Single Pulse 
each time TC is 
TINTO 


reached until a new 
command is loaded. 


• 
BOG4 is jumper 
selectable 
as an auxiliary 
baud rate generator 
to the 


USARTs or as a cascaded 
output 
to TINT1. BOG4 may be used in modes 


2 and 4 only when configured 
as a cascaded 
output. 


Interrupt 
Vector 
Interrupt 


Source 
Location 
Level 


Power Fail 
TRAP 
24H 
1 


8253TINT1 
RST7.5 
3CH 
2 


8155 TINTO 
Ring Indicator 
(1) 
RST6.5 
34H 
3 


Carrier Detect 


Flag Interrupt 
RST5.5 
2CH 
4 


INTO/-INT7/(1 of 8) 
RXRDYO 
INTR 
Program- 
5-12 


TXRDYO 
mabie 


RXRDY1 
TXRDY1 
RXRDY2 
t 


TXRDY2 
RXRDY3 
TXRDY3 


(1) Four ring indicator interrupts 
and four carrier detect interrupts are 


summed to the RST 6.5 input. The 8155 may be interrogated 
to inspect 


anyone of the eight signals. 


a bus master and intelligent slave (SeeSystem Program- 
ming). Eight inputs from the serial ports are monitored 
to detect a ring indicator and carrier detect from each of 
the four channels. These eight interrupt sources are 
summed to a single interrupt level of the 8085A CPU. If 
one of these eight interrupts occur, the 8155 PPIcan then 
be interrogated to determine which port caused the 
interrupt. Finally, a jumper selectable Power Fail Inter- 
rupt is available from the Multibus to detect a power 
down condition. 


8085 Interrupt 
- 
Thirteen of the twenty-two interrupt 


sources are available directly to four interrupt inputs of 
the on-board 8085A CPU. Requests routed to the 8085A 
interrupt inputs, TRAP, RST 7.5, RST 6.5 and RST 5.5 
have a unique vector memory address. An 8085A jump 
instruction 
at each of these addresses then provides 


software linkage to interrupt service routines located 
independently anywhere in the Memory. All interrupt 
inputs with the exception of the TRAP may be masked 
via software. 


8259A Interrupts 
- 
Eight interrupt sources signaling 


transmitter and receiver ready from the four USARTsare 
channeled directly to the Intel 8259A PIC.The PIC then 
provides vectoring for the next eight interrupt levels. 
Operating mode and priority assignments may be recon- 
figured dynamically 
via software at any time during 
system operation. The PIC accepts transmitter and re- 
ceiver 
interrupts 
from 
the 
four 
USARTs. It 
then 
determines 
which 
of 
the 
incoming 
requests 
is 
of 
highest priority, determines whether this request is of 
higher priority than the level currently being serviced, 
and, if appropriate, issues an interrupt to the CPU. The 
output of the PIC is applied directly to the INTR input of 
th.e8085A. Any combination of interrupt levels may be 
masked, via software, by storing a single byte in the 
interrupt 
mask register of the PIC. When the 8085A 
responds to a PIC interrupt, the PIC will generate a 
CALL instruction 
for each interrupt 
level. These ad- 
dressses are equally spaced at intervals of 4 or 8 (soft- 
ware selectable) bytes. Interrupt response to the PIC is 
software programmable to a 32- or 64-byte block of 
memory. Interrupt sequences may be expanded from 
this block with a single 8085A jump instruction at each 
of these addresses. 


Interrupt Output - 
In addition, the iSSC 544 board may 
be jumper selected to generate an interrupt from the on- 
board serial output data (SOD) of the 8085A. The SOD 
signal may be jumpered to anyone of the 8 MULTISUS 
interrupt lines (INTO/·INT7/) to provide an interrupt signal 
directly to a bus master. 


Power-Fail Control 


Control logic is also included to accept a power·fail 
interrupt in conjunction with the AC-Iow signal from the 
iSSC 635 Power Supply or equivalent. 


Expansion Capabilities 


When the iSSC 544 board is used as a single board com- 
munications controller, memory and I/Ocapacity may be 
expanded and additional 
functions 
added using Intel 
MULTIBUS™ compatible 
expansion 
boards. 
In this 


mode, no other bus masters may be configured in the 
system. 
Memory 
may be expanded 
to a 65K byte 
capacity by adding user specified combinations of RAM 
boards, EPROM boards, or combination boards. Inputl 
output capacity may be increased by adding digital I/O 
and analog I/Oexpansion boards. Furthermore, multiple 
iSSC 544 boards may be included 
in an expanded 
system using one iSSC 544 board as a single board com- 
munications 
computer 
and additional 
controllers 
as 
intelligent slaves. 


In the system programming environment, the iSSC 544 
board appears as an additional 
RAM memory module 


when used as an intelligent slave. The master CPU com- 
municates with the iSSC 544 board as if it were just an 
extension of system memory. Secause the iSSC 544 
board is treated as memory by the system, the user is 
able to program into it a command structure which will 
allow the iSSC 544 board to control 
its own I/O and 
memory operation. To enhance the programming of the 
iSSC 544 board, the user has been given some specific 
tools. The tools are: 1)the flag interrupt, 2) an on·board 
RAM memory area that is accessible to both an off- 
board CPU and the on-board 8085A through which a 
communications 
path can exist, and 3) access to the 


, bus interrupt line. 


Flag Interrupt - 
The Flag Interrupt is generated any- 


time a write command is performed by an off-board CPU 
to the base address of the iSSC 544 board's RAM. This 
interrupt provides a means for the master CPU to notify 
the.iSSC 544 board that it wishes to establish a com- 
munications sequence. In systems with more than one 
intelligent slave, the flag interrupt provides a unique in- 
terrupt 
to 
each 
slave 
outside 
the 
normal 
eight 
MULTISUS interrupt lines (INTO/-INT7/). 


On·Board RAM 
- 
The on-board 16K byte RAM area that 
is accessible to both an off·board CPUand the on-board 
8085A can be located on any 4K boundary in the system. 
The selected base address of the iSSC 544 RAM will 
cause a flag interrupt when written into by an off-board 
CPU. 


Bus Access 
- 
The third 
tool 
to 
improve 
system 
operation as an intelligent slave is access to the Multi- 
bus interrupt lines. The iSSC 544 board can both re- 
spond to interrupt signals from an off-board CPU, and 
generate an interrupt 
to the off-board 
CPU via the 


MULTISUS. 


The development cycle of iSSC 544 board based prod- 
ucts may be significantly 
reduced using the Intellec 
series microcomputer development systems. The Intel- 
lee resident macroassembler, text editor, and system 
monitor greatly simplify the design, development and 
debug of iSSC 544 system software. An optional ISIS·II 
.diskette operating system provides a linker, object code 
locater, 
and 
library 
manager. 
A unique 
in-circuit 


emulator 
(ICE-85) option 
provides the 
capability 
of 
developing and debugging software directly on the iSSC 
544 board. 


Synchronous - 
5·8 bit characters; automatic sync 
insertion; parity. 


Asynchronous - 
5-8bit characters; break character 
generation; 1, 1V2, or 2 stop bits; 
false start bit detection; break 
character detection. 


Frequency 
(KHz)1 
Baud RalelHz)2 


(Software 
Selectable) 
Synchronous 
Asynchronous 


.•. 16 
.•.64 


153.6 
-- 
9600 
2400 


76.8 
-- 
4800 
1200 


-38.4 
38400 
2400 
600 
19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


6.98 
6980 
-- 
110 


Notes: 
1) Frequency 
selected 
by 1/0 writes 
of appropriate 
16-bit frequency 
factor 
to Baud Rate Register. 


2) Baud rates shown 
here are only a sample 
subset 
of possible 
software 
programmable 
rates available. 
Any frequency 
from 
18.75 Hz to 614.4 


KHz may be generated 
utilizing 
on-board crystal 
oscillator 
and 16·bit 
Programmable 
Interval 
Timer (used here as a frequency 
divider). 


Word Size - 
8,16 or 24 bits/instruction; 
8 bits of data 


Cycle Time -1.45/usec 
± .1% for fastest executable 


instruction; 
i.e. four clock cycles. 


Clock Rate - 
2.76 MHz ± .1% 


System 
Access 
Time 


Dual port memory - 
740 nsec 


Note: Assumes 
no refresh 
contention 


Memory 
Capacity 


On·Board ROM/PROM- 
4K, or 8K bytes of user installed 
ROM or EPROM. 


On·Board Static RAM - 
256 bytes on 8155. 


On·Board Dynamic RAM (on·board access) - 
16K bytes. 
Integrity 
maintained 
during 
power failure 
with 
user· 


furnished batteries (optional). 


On·Board Dyanmic RAM (MULTIBUS access) - 
4K, 8K, 


or 16K-bytes available to bus by switch selection. 


Memory Addressing 


On·Board ROM/PROM - 
O-OFFF(using 2716 EPROMsor 
masked ROMs); 0-1FFF (using 2732AEPROMs) 


On·Board Static Ram - 
256 bytes: 7FOO-7FFF 


On·Board Dynamic RAM (on·board access) - 
16K bytes: 
8000·BFFF. 


On·Board Dynamic RAM (MULTIBUS access) - 
any 4K 


increment 
OOOOO-FFOOO 
which 
is switch 
and jumper 


selectable. 4K- 8K· or 16K-bytes can be made available 
to the bus by switch selection. 


1/0 Capacity 


Serial - 
4 programmable channels using four 8251A 


USARTs. 
Parallel - 
10 programmable lines available for Bell 801 


ACU, or equivalent use. Two auxiliary jumper selectable 
signals. 


110Addressing 


On-Board Programmable I/O 


Port 
oala 
Control 


USARTO 
DO 
01 
USART 1 
02 
03 


USART2 
04 
05 
USART3 
06 
07 
8155 PPI 
E9(Port 
A) 
E8 
EA(Port 
B) 


EB(PortC) 


Interrupts 


Addresses for 8259A Registers (Hex notation, 
I/O ad- 
dress space) 


E6 
Interrupt request register 
E6 
In-service register 
E7 
Mask register 
E6 
Command register 
E7 
Block address register 
E6 
Status (polling register) 


Note: Several registers 
have the same physical 
address: 
Sequence 
of 
access and one data bit of the control 
word determines 
which 
register 
will respond. 


Interrupt levels routed to the 8085 CPU automatically 
vector the processor to unique memory locations: 
24 
TRAP 
3C 
RST7.5 
34 
RST6.5 
2C 
RST5.5 


Timers 


Addresses for 8253 Registers (Hex notation, I/O address 
space) 


Programmable Interrupt Timer One 
D8 
TimerO 
BDGO 
D9 
Timer 1 
BDG1 
DA 
Timer 2 
BDG2 
DB 
Control register 


Programmable Interrupt Timer Two 
DC 
TimerO 
BDG3 
DD 
Timer 1 
BDG4 
DE 
Timer 2 
TINT1 
DF 
Control register 


Address lor 8155 Programmable Timer 
E8 
Control 
ED 
Timer (LSB) 
TINTO 
EC 
Timer (MSB) TINTO 


Input 
frequencies 
- 
Jumper 
selectable 
reference 


1.2288 MHz±.1% 
(.814 usee period nominal) or 1.843 


MHz± .1% crystal (0.542usee period, nominal) 


Output Frequencies (at 1.2288MHz) 


Single 
timer/counter 
Dual timer/counter 


Function 
(two timers 
c.scadadl 


Mln 
Max 
Mln 
Max 


Real-time 
1.63 usee 
53.3 usee 
3.26 usee 
58.25 min 


interrupt 
interval 


Rate Generator 
18.75 Hz 
614.4 KHz 
0.00029 Hz 
307.2 KHz 


(frequency) 


Serial 1/0 - 
EIA Standard RS232Csignals provided and 


supported: 
Carrier Detect 
Clear to Send 
Data Set Ready 
Data Terminal Ready 
Request to Send 
Receive Clock 


Receive Data 
Ring Indicator 
Secondary Receive Data· 
Secondary Transmit Data· 
Transmit Clock 
Transmit Data 
DTETransmit Clock 


Parallel I/O - 
Four inputs and eight outputs (includes 


two jumper selectable auxiliary 
outputs). All signals 


compatible with EIA Standard RS232C.Directly compat- 
ible with 
Bell Model 801 Automatic 
Calling Unit, or 


equivalent. 


MULTIBUs - 
Compatible with iSBC MULTIBUS. 


On· Board Addressing 


All communications to the parallel and serial I/O ports, 
to the timers, and to the interrupt controller, are via read 
and write commands from the on-board 8085ACPU. 


Auxiliary 
Power 


An auxiliary power bus is prOVided to allow separate 
power to RAM for systems requiring battery backup of 
read/write memory. Selection 
of this 
auxiliary 
RAM 


power bus is made via jumpers on the board. 


Interface 
Pins 
Centers 
Mating 
Connectors 
(qty) 
(in.) 


Bus 
86 
0.156 
Viking 
2KH43/9AMK12 


ParailelllO 
50 
0.1 
3M 3415-000 or 
AMP 88083·1 


Serial 
110 
26 
0.1 
3M 3462·000 or 
AMP 88373·5 


Memory 
Protect 


An active-low TTL compatible memory protect signal is 
brought out on the auxiliary 
connector 
which, when 
asserted, disables read/write access to RAM memory on 
the board. This input is provided for the protection of 
RAMcontents during the system power-downsequences. 


Function 
Characteristic 
Sink Current 
(mAl 


Data 
Tri-state 
50 


Address 
Tri-stat~ 
15 


Commands 
Tri-state 
32 


Physical 
Characteristics 


Width: 
30.48em (12.00inches) 
Depth: 
17.15em (6.75inches) 
Thickness: 
1.27em (0.50inch) 
Weight: 
3.97gm (14ounces) 


Currenl 
Requirements 


Configuration 
VCC = + SV 
VOO= 
:!:12VI 
Voa = - SV(3) 
VAA= 
-12V 


±5% (max) 
±5%(maJl) 
:t5% (max) 
±S% 
(rnax) 


With4K 


EPROM 
Ice= 
3.4 mall 
100= 
350mA 
18S= SmA max 
IAA = 200mA 
(using 2716) 
ma, 
ma, 
ma, 


Without 


3.3A mal( 
350 mA mal( 
5mAmal( 
200 mA mal( 
EPROM 


RAM only (1) 
390 mA mal( 
176 mA mal( 
5 mA mal( 
- 


RAM(2) 
390 mA mal( 
20mA 
mal( 
refresh 
only 
SmA mal( 


Noles: 
1. For operational 
RAM only. for AUX power supply 
rating. 


2 For RAM refresh 
only. 
Used for battery 
backup 
requirements 
No RAM 


accessed 


3. VBB is normally 
derived 
on· board from 
VAA. eliminating 
the need for a 


VBB 
supply. 
If It is desired 
to supply 
VBB 
from 
the 
bus. 
the 
current 


requirement 
IS as shown 


Environmental 
Characteristics 


Operating Temperature: O°Cto 55°C (32°F to 131°F) 
Relative Humidity: To 90% without condensation 


Reference 
Manual 


502160 - 
iSBC 544 Intelligent Communications Con- 
troller Board Hardware Reference Manuai (NOT SUP- 
PLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative. distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California.95051. 


Part Number 
iSBC544 


Description 


Intelligent Communications 
Controller 


iSBC™ 534 (or pSBC 534 *) 


FOUR CHANNEL 
COMMUNICATION 
EXPANSION 
BOARD 


• Serial 1/0 expansion through four pro· 


grammable synchronous and asyn· 
chronous communications 
channels 


• Individual software programmable 


baud rate generation for eac;:hserial 
1/0 channel 


• Two independent programmable 16·bit 


interval timers 


• Sixteen maskable interrupt request 
lines with priority encoded and pro· 
grammable interrupt algorithms 


• Jumper selectable interface register 


addresses 


• 16·bit parallel 1/0 interface compatible 
with Bell 801 automatic calling unit 


• RS232C/CCITT V.24 interfaces plus 
20 mA optically isolated current loop 
interfaces (sockets) 


• Programmable digital loopback for 


diagnostics 


• Interface control for auto answer and 


auto originate modems 


The iSBC 534 Four Channel Communication 
Expansion Board is a member of Intel's complete 
line of memory and I/O 
expansion boards. The iSBC 534 interfaces directly to any single board computer via the MULTIBUS to provide expan- 
sion of system serial communications 
capability. 
Four fully programmable synchronous 
and asynchronous 
serial chan- 
nels with RS232C buffering 
and provision for 20 mA optically 
isolated current loop buffering 
are provided. Baud rates, 


data formats, and interrupt 
priorities 
for each channel are individually 
software selectable. 
In addition to the extensive 
complement 
of EIA Standard RS232C signals provided, the iSBC 534 provides 16 lines of RS232C buffered program- 
mable parallel 110. This interface is configured 
to be directly compatible 
with the Bell Model 801 auiomatic 
calling unit. 


These capabilities 
provide a flexible and easy means for interfacing 
Intel iSBC based systems to RS232C and optically 
isolated current loop compatible 
terminals, 
cassettes, 
asynchronous 
and synchronous 
modems, and distributed 
pro- 


cessing networks. 


FUNCTIONAL 
DESCRIPTION 
Communications 
Interface 
Four programmable communications interfaces using 
Intel's 
8251A Universal Synchronous/Asynchronous 
Receiver/Transmitter 
(USART) are contained 
on the 
board.' Each USARTcan be programmed by the system 
software to individually select the desired asynchronous 
or synchronous serial data transmission technique (in- 
cluding IBM Bisync). The mode of operation (i.e., syn- 
chronous 
or asynchronous), 
data format, 
control 
character format, parity, and baud rate are all under pro- 
gram control. Each 8251A provides full duplex, double 
buffered transmit and receive capability. Parity, overrun, 
and framing error detection are all incorporated in each 
USART.Each set of RS232Ccommand lines, serial data 
lines, and signal ground lines are brought out to 26-pin 
edge connectors that mate with RS232Cflat or round 
cables. 


16·Bit Interval Timers 
The iSBC 534 provides six fully programmable and in- 
dependent BCD and binary 16-bit interval timers utiliz- 
ing two Intel 8253 programmable interval timers.' 
Four 


timers are available to the systems designer to generate 
baud rates for the USARTs under software control. 
Routing for the outputs from the other two counters is 
jumper selectable. Each may be independently routed 
to the programmable interrupt controller to provide real 
time clocking or to the USARTs(for applications requir- 
ing different transmit and receive baud rates). In utiliz- 
ing the iSBC 534, the systems designer simply con- 
figures, via software, each timer independently to meet 
system requirements. Whenever a given baud rate or 


time delay is needed, software commands to the pro- 
grammable timers select the desired function. Three 
functions of these timers are supported on the iSBC 
'534,as shown in Table 1.The contents of each counter 
may be read at any time during system operation. 


Function 
Operation 


Interrupt on ter- 
When terminal count is reached 
minal count 
an interrupt request is generated. 
This function is used for the gen- 
eration of real-time clocks. 


Rate generator 
Divide by N counter. The output 
will go low for one input clock cy- 
cle and high for N - 1 input clock 
periods. 
Square wave rate 
Output will remain high for one· 


generator 
half the count and low for the 
other half of the count. 


Interrupt 
Request Lines 
Two independent Intel 8259A programmable interrupt 
controllers 
(PIC's) provide vectoring for 16 interrupt 
levels.' As shown in Table 2,a selection of three priority 
processing 
algorithms 
is available 
to the system 
designer. The manner in which requests are serviced 
may thus be configured to match system requirements. 
Priority assignments may be reconfigured dynamically 
via software at any time during system operation. Any 
combination of interrupt levels may be masked through 
storage, via software, of a single byte to the interrupt 
mask register of each PIC. Each PIC's interrupt request 


I~J9 


, 


lI'\IftRMUPT 


REQuEST 


lllllES 


output line may be jumper selected to drive any of the 
nine interrupt lines on the MULTIBUS. 


Table 2. Interrupt Priority Options 


Algorithm 
Operation 


Fully 
Interrupt request line priorities fixed at 0 


nested 
as highest, 7 as lowest. 


Auto- 
Equal priority. Each level, after receiving 


rotating 
service, becomes the lowest priority level 
until next interrupt occurs. 


Specific 
System software assigns lowest priority 


priority 
level. Priority of all other levels based in 
sequence 
numerically 
on this 
assign- 
ment. 


Interrupt Request Generation - 
As shown in Table 3, in- 
terrupt requests may originate from 16 sources. Two 
Jumper selectable Interrupt requests (8 total) can be 
automatically 
generated 
by each 
USART when 
a 


character is ready to be transferred to the MULTIBUS 
system bus (i.e., receive buffer is full) or a character has 
been transmitted 
(transmit 
buffer is empty). Jumper 


selectable requests can be generated by two of the pro- 
grammable timers (PITs),and six lines are routed directly 
from peripherals to accept carrier detect (4lines), ring in- 
dicator, and the Bel1801present next digit request lines. 


Systems Compatibility 
The iSBC 534 provides 16 RS232Cbuffered parallel I/O 
lines Implemented 
utilizing 
an Intel 8255A program- 


Interrupt 
Request 
PIC 0 
PIC 1 
Line 


0 
PORT0 Rx ROY 
PIT 1 counter 1 
1 
PORT0 Tx ROY 
PIT 2 counter 2 
2 
PORT 1 Rx ROY 
Ring indicator (all ports) 
3 
PORT 1 Tx ROY 
Present next digit 
4 
PORT2 Rx ROY 
Carrier detect port 0 
5 
PORT2 Tx ROY 
Carrier detect port 1 
6 
PORT3 Rx ROY 
Carrier detect port 2 


7 
PORT3 Tx ROY 
Carrier detect port 3 


mabie peripheral interface (PPI)configured to operate in 
mode 0.' These lines are configured to be directly com- 
patible with the Bell 801 automatic calling unit (ACU). 
This capability allows the iSBC 534 to interface to Bell 
801 type ACUs and up to four modems or other serial 
communications devices. For systems not requiring in- 
terface to an ACU,the parallel 110 lines may also be used 
as general purpose RS232Ccompatible control lines in 
system implementation. 


• Complete 
operational 
details 
on the Intel 8251A 
USART, 
the Intel 8253 
Programmable 
Interval Timer, the Intel 8255A Programmable 
Peripheral 
In- 
terface. and the Intel 8259A Programmable 
Interrupt Controller 
are contained 


In the Intel Component 
Data Catalog. 


Serial Communications 
Characteristics 


Synchronous - 
5-8 bit characters; internal or external 


character synchronization; automatic sync insertion. 
Asynchronous 
- 
5-8 bit characters; break character 


generation' 1, 1V2, or 2 stop bits; false start bit detec- 
tion 


Frequency2 
B~ud Rate (~ 


(kHz, Software Selectable) 
Synchronous 
Asynchronous 


153.6 
768 
384 
192 
96 
48 
698 


38400 
19200 


9600 
4800 
6980 


Not8s: 
1. Baud rates 
shown 
here are only 
a sample 
subset 
of 
possible 


software-programmable 
rates 
available 
Any frequency 
tram 
18.75 Hz to 


6144kHz 
may 
be generated 
utilizing 
on-board 
crystal 
oscillator 
and 


16·bit programmable 
interval 
timer 
(used here as frequency 
divider). 


2 
Frequency 
selected 
by I/O writes 
of appropriate 
16-bit frequency 
fac- 
tor to Baud Rate Register 


Interval Timer and Baud Rate Generator 
Frequencies 


Input Frequency (On-Board Crystal Oscillator) - 
1.2288 
MHz± 0.1% (0.813I's period, nominal) 


Single 
Timer 
DualfTimer 
Counter 


Function 
(Two Timers 
Cascaded) 


Min 
Max 
Mln 
Max 


Real-Time 
58.25 
Interrupt 
1.631'S 
53.3ms 
3.261's 
minutes 
Interval 
I 


Rate Generator 
18.75 Hz 
614.4 kHz 
0.0029 H2 
(Frequency) 
307.2 kHz 


Interfaces - 
RS232C Interfaces 
EIA Standard RS232CSignals provided and supported: 
Carrier detect 
Receive data 
Clear to send 
Ring indicator 
Data set ready 
Secondary receive data 


Data terminal ready 
Secondary transmit data 


Request to send 
Transmit clock 
Receive clock 
Transmit data 


Parallel I/O - 
8 input lines, 8 output lines, all signals 
RS232Ccompatible 
Bus - 
All signals MULTIBUS system bus compatible 


1/0 Addressing 
The USART, interval 
timer, 
interrupt 
controller, 
and 


parallel 
interface 
registers of the iSBC 534 are con- 


figured as a block of 16 1/0 address locations. The loca- 
tion of this block is jumper selectable to begin at any 
16-byte 1/0 address boundary (Le., OOH,10H, 20H, etc.). 


1/0 Access Time 
400 ns 
USART registers 
400 ns 
Parallel 1/0 registers 
400 ns 
Interval timer registers 


400 ns 
Interrupt controller registers 


Interface 
Pins 
Centers 
Mating Connectors 
Cable 
(qty) 
(in.) 


Bus 
86 
0.156 
Viking 
2KHa3J9AMK12 
N/A 


Serial and 


26 
01 
3M 3462.QOOl or 
Inlel 


paratlel I/O 
TI H312113 
iSBC955 


Function 
Supplier 
Part Number 


Driver 
Fairchild 
4N33 
General 
Electric 


Monsanto 


Receiver 
Fairchild 
4N37 
General 
Electric 
Monsanto 


Physical 
Characteristics 
Width - 
12.00 in. (30.48 cm) 


Height - 
6.75 in. (17.15 cm) 


Depth - 
0.50 in. (1.27 cm) 


Weight - 
14 oz (398 gm) 


Electrical 
Characteristics 
Average DC Current 


VoUago 
Without 
With 


Opta-Isolalors 
Opla·lsolators' 


VCC 
= 
+5V 
1.9 A, max 
1.9 A, max 


VOO = 
+ 12V 
275 mA, max 
420 mA, max 


VAA 
= 
-12V 
250 mA, max 
400 mA, max 


Note 


1. 
With 
four 4N33 and four 4N37 optc-isolator 
packages 
installed 
in 
sockets 
provided 
to implement 
tour 20 mA current 
loop interfaces. 


Environmental 
Characteristics 


Operating Temperature - 
O°C to + 55°C 


Reference 
Manual 


502140-002 - 
iSBC 534 Hardware Reference Manual 
(NOT SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California 95051. 


Part Number 
SBe 534 


Description 
Four Channel Communication 
Ex- 
pansion Board 


iSBC®88/45 


ADVANCED 
DATA COMMUNICATIONS 
PROCESSOR 
BOARD 


• Three HOLC/SOLC half/full-duplex 


communication 
channels 
- 
optional 


ASYNC/SYNC 
on two channels 


• Supports 
RS232C (including 
modem 


support), 
CCITT V.24, or RS422A1449 


interfaces 


• On-board OMA supports 
800K baud 


operation 


• Self-clocking 
NRZI SOLC loop data 


link interface 
- 
point-to-point 
- 
multidrop 


• Software 
programmable 
baud rate 


generation 


• iAPX 88/10 (8088-2) Microprocessor 


operates 
at 8 MHz 


• iSBC@337 Numeric 
Oata Processor 


option 
supported 


• 16K bytes static 
RAM (12K bytes 


dual-ported) 


• Four 28-pin JEOEC sites for 
EPROM/RAM expansion; 
four additional 


28-pin JEOEC sites added with iSBC@; 
341 board 


• MULTIBUS(!; interface 
supports 


Multimaster 
configuration 


The iSBC 88/45 Advanced 
Data Communications 
Processor 
(ADCP) Board adds 8 MHz, iAPX 88/10 (8088-2) 
8-bit microprocessor-based 
communications 
flexibility 
to the Intel line of OEM microcomputer 
systems. 


The iSBC 88/45 ADCP board offers 
asynchronous, 
synchronous, 
SDLC, and HDLC serial 
interfaces 
for 
gateway 
networking 
or general purpose 
solutions. 
The iSBC 88/45 ADCP board provides 
the CPU, system 
clock, 
EPROM/RAM, 
serial I/O ports, priority 
interrupt 
logic, and programmable 
timers to facilitate 
higher- 
level application 
solutions. 


The 101l0•••.'n9 are Irade,narks 
,I Il"le' 
CorporatIOn 
and may be used only 10 descnbe 
Intet products 
Intel. 
CREDIT 
Index 
InSlte 
Intellec. 
lIbrary 
Manager 
MeQacha!';SI5. 


M,Cfomap 
MUI TIBuS 
PROMPT 
UPI, "Scope 
Promwarc, 
MeS. ICE, IRMX 
l$BC. ,sax, 
MUlTIMOOULE 
and ICS Inlet CorporatIon 
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for the ,Jse 01 any 
Clrcullry 
ethel 
Iha!1 eH, u Iry Ill:TIOOd,ea,n a;; Inlel product 
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Three Communication 
Channels 


Three programmable 
HOLC/SOLC serial interfaces 


are provided 
on the iSBC 88/45 AOCP board. The 


SOLC interface 
is familiar 
to IBM system 
and ter- 
minal 
equipment 
users. 
The 
HOLC 
interface 
is 


known 
by users of CCITI's 
X.25 packet 
switching 


interface. 


One channel 
utilizes 
an Intel 
8273 controller 
to 


manage 
the serial 
data transfers. 
Accepting 
the 


8-bit data bytes from the local 
bus, the 8273 con· 
troller 
translates 
the data into the HOLC/SOLC for- 
mat. The channel operates 
in half/full-duplex 
mode. 


In addition 
to the 
synchronous 
mode, 
the 8273 


controller 
operates 
asynchronously 
with 
NRZI en- 


coded data which 
is found 
in systems 
such as the 


IBM 3650 Retail Store System. 
An SOLC loop con· 
figuration 
using iSBX 352 and iSBC 88/45 products 


is shown 
in Figure 
1. 


The two additional 
channels 
utilize 
the Intel 8274 


Multi-Protocol 
Serial Controller 
(MPSC). The MPSC 


provides 
two 
independent 
half/full-duplex 
serial 


channels 
which 
provide 
asynchronous, 
syn- 
chronous, 
HOLC or SOLC protocol 
operations. 
The 


sync and async protocol 
operations 
are commonly 


used to communicate 
with 
inexpensive 
terminals 


and systems. 


The three serial channels 
of the iSBC 88/45 AOCP 


board offer communications 
capability 
to manage 


a gateway 
application. 
The gateway 
application, 
as shown in Figure 1, manages diverse protocol 
re- 
quirements 
for data movement 
between 
channels. 
Typical 
protocol 
management 
software 
layers im- 


plemented 
by the user include 
SNA terminal 
inter- 


faces to IBM systems. 


For high-speed 
communications, 
one MPSC chan- 


nel has a OMA capacity 
to support 
an 800K baud 


rate. The second 
channel 
attached 
to the MPSC is 


capable 
of 
simultaneous 
800K 
baud 
operation 


when configured 
with 
OMA capability, 
but is con- 


nected to an RS232C interface 
which 
is defined 
as 


20K baud maximum. 
Figure 2 shows an RS422A1449 


multidrop 
application 
which 
supports 
high-speed 


operation. 


Interfaces 
Supported 


The iSBC 88/45 AOCP board provides 
an excellent 


foundation 
to support 
these electrical 
and diverse 


software 
drivers 
protocol 
interfaces. 
The control 


lines, serial data lines, and signal 
ground 
lines are 


brought 
out to the three double-edge 
connectors. 


Figure 
3 shows 
the cable 
to connector 
construc- 


tion. 
Two 
connectors 
are 
pre-configured 
for 
RS422A/449. 
All three 
channels 
are configurable 


for 
RS232C/CCITT 
V.24 
interfaces 
as shown 
in 


Table 1. 


Table 1. iSBC'" 88/45 Supported 
Configurations 


Synchronous 
Asynchronous 


Connection 
Modem 
Direct 
Modem" 
Direct 


point-to·point 
X·· 
X 
X 
X 


multidrop 
X 
X 
X 
X 


loop 
N.A. 
N.A. 
C 
C 
(only) 
(only) 


• Modem should not respond to break. 


•• Channels A. S, and C denoted by X. 


I, ;S8." 35'.1 
I ;58'" 352 I 


_I 
s==r'_ 


TT 


SO 


RT 


iSBC' 
88145 
BOARD 


RO 


TR 


0" 
1 


CONNECTOR 
CONNECTOR 
I 
J, 
J, 


TR 
0" 
SO 
TT 
RO 
RT 
TR 
0•• 
SO 
TT 
RO 
RT 


iSBC' 
88J45 
iSBC' 
88145 


BOARD 
BOARD 


SLAVE 
A 
SLAVE 
8 


NOTE: The last slave device in the system must contain termination resistors on all signal lines received by the siave board. 


The master device contains bias resistors on all signai lines. 


intel 


Self Clocking Point·To·Point Interface 


The 
ISBC 88/45 ADCP 
board 
is used 
In an asyn· 


chronous 
mode 
interface 
when 
configured 
as 


shown 
in Figure 
4. The point·to·point 
RS232C ex· 
ample 
uses 
the 
self·clocking 
mode 
interface 
for 


NRZI 
encoding/decoding 
of 
data. 
The 
digital 


phase·lock 
loop 
allows 
operation 
of the interface 


in either 
half/duplex 
or full/duplex 
implementation 


with 
or without 
modems. 


R,C 


R,O 


RTS 
crs iSBC' 
88/45 


TxC 
BOARD 
hO 


OSR 


OTR 


T,C 
T,O 


RTS 
Isec' 88/45 ers 
BOARD 
Rxe 


R,O 


OTR 


OSR 


Figure 4. Self·Clocking 
or Asynchronous 
Point·to· 
Point Modem 
Interface 
Configuration 
Example 
- RS232C 


Synchronous Point-To-Point Interface 


Figure 
5 shows 
a sychronous 
point·to·point 
mode 


of operation 
for the iSBC 88/45 ADCP 
board. 
This 


RS232C example 
uses a modem 
to generate 
the re- 


ceive 
clock 
for coordination 
of the data 
transfer. 


The iSBC 88/45 ADCP 
board 
generates 
the trans- 


mit sychronizing 
clock 
for synchronous 
transmis- 


sion. 


RTS 


CTS 


jSBC' 
88/45 
hD 


BOARD 
RxO 


OTR 


OSR 


RTS 


CTS 


RxD 
iSBC' 
88/45 
rllo 
BOARD 


OSR 


OTR 


Figure 5. Synchronous 
Point·to·Point 
Modem 
Interface 
Configuration 
Example 
- 


RS232C 


Central Processing Unit 


The central 
processor 
for the iSBC 88/45 Advanced 


Data Communications 
Processor 
board 
is Intel's 


8088 
microprocessor 
operating 
at 
8 
MHz. 
The 


microprocessor 
interface 
to 
other 
functions 
is 


illustrated 
in Figure 
6. The microprocessor 
archi- 


tecture 
is designed 
to effectively 
execute 
the ap· 


plication 
and 
networking 
software 
written 
in 


higher·level 
languages. 


This architectural 
support.includes 
four 16-bit byte 


addressable 
data 
registers, 
two 
16-bit 
memory 


base pointer 
registers 
and two 
16-bit 
II1dex regis· 


ters. 
These 
registers 
are addressable 
through 
24 


different 
operand 
addressing 
modes 
for compre- 


hensive 
memory 
addressing 
and for high-level 
lan- 


guage 
data structure 
manipulation. 


The 
stack-oriented 
architecture 
readily 
supports 


Intel's 
iRMX executives 
and iMMX multiprocessing 


software. 
Both 
software 
packages 
are designed 


for modular 
application 
programming. 
Facilitating 


the fast 
inter-module 
communications, 
the 4-byte 


instruction 
queue 
supports 
program 
constructs 


needed 
for real-time 
systems 


Since 
programs 
are segmented 
between 
pure pro- 


cedure 
and 
data, 
four 
segment 
registers 
(code, 


stack, 
data, 
extra) 
are avail-able 
for 
addressing 
1 


megabyte 
of memory 
space. 
These 
registers 
con· 


tain 
the offset 
values 
used 
to address 
a 64K byte 


segment. 
The 
registers 
are 
controlled 
explicitly 


through 
program 
control 
or implicitly 
by high-level 


language 
functions 
and instructions. 


The real-time 
system 
software 
can also 
utilize 
the 


programmable 
timers 
as shown 
in Table 2 and var- 


ious 
interrupt 
control 
modes 
available 
on 
the 


ADCP 
board 
to have responsive 
and effective 
ap- 


plication 
solutions. 


Function 
Operation 


Interrupt on 
An interrupt 
is generated 
on 


Terminal 
terminal 
count 
being 
reached. 


Count 
This function 
is useful for gener· 


ation of real-time clocks. 


Rate 
Divide by N counter. 
Based on 


Generator 
the input clock period, the output 
pulse remains low until the count 
is expired. 


Square Wave 
Output remains high for one-half 


Generator 
the count, 
goes low for the reo 


mainder of the count. 


Software 
Output 
remains high until count 


Triggered 
expires, 
then goes low for one 


Strobe 
clock period. 


Numeric Data Processor Extension 


The 8088 instruction 
set includes 
8-bit 
and 
16-bit 


signed 
and 
unsigned 
arithmetic 
operators 
for bi- 


intel 


nary, 
BCD, 
and 
unpacked 
ASCII 
data. 
For 
en- 
hanced 
numerics 
processing 
capability, 
the iSBC 


337 MUL T1MODULE 
Numeric 
Data 
Processor 
ex- 


tends 
the 8088 architecture 
and data set'. 


The extended 
numerics 
capability 
includes 
over 
60 numeric 
instructions 
offering 
arithmetic, 
trigo- 
nometric, 
transcendental, 
logarithmic, 
and 
expo- 
nential 
instructions. 
Many 
math-oriented 
applica- 
tions 
utilize 
the 16-, 32-, and 64-bit 
integer, 
32- and 
64-bit 
floating 
point, 
18-digit 
packed 
BCD, 
and 
80-bit temporary 
data types. 


16K Bytes Static Ram 


The iSBC 88/45 ADCP board contains 
16K bytes of 
high-speed 
static 
RAM, with 
12K bytes dual-ported 
which 
is addressable 
from 
other 
MULTIBUS 
de- 
vices. 
When 
coupled 
with 
the 
high-speed 
DMA 


capability 
of the iSBC 88/45 ADCP board, the dual- 
ported 
memory 
provides 
effective 
data communi- 


cation 
buffers. 
The dual-ported 
memory 
is useful 


for interprocessor 
message 
transfers. 


1 The iSBC 337 board requires the iSBC 88/45 ACDP board be 
jumpered to provide 4 MHz operation. 


Interrupt Capability 


The 
iSBC 
88/45 
ADCP 
board 
provides 
nine 
vec- 


tored 
interrupt 
levels. 
The highest 
level is the NMI 


(Non-Maskable 
Interrupt) 
line. The additional 
eight 


interrupt 
levels 
are vectored 
via the 
Intel 
8259A 


Programmable 
Interrupt 
Controller 
(PIC). As shown 
in 
Table 
3, four 
priority 
processing 
modes 
are 


available 
to 
match 
interrupt 
servicing 
require- 


ments. 
These 
modes 
and priority 
assignments 
are 


dynamically 
configurable 
by the system 
software. 


Mode 
Operation 


Nested 
Interrupt request line priorities 
fixed; 


interrupt 0 is the highest and 7 is the 
lowest. 


Auto- 
The interrupt priority rotates; once an 


Rotating 
interrupt 
is serviced 
it becomes the 


lowest priority. 


Specific 
System software assigns lowest level 


Priority 
priority. The other levels are sequenced 
based on the level assigned. 


Polled 
System software examines priority in- 
terrupt via interrupt 
status register. 


~-~ 


I - ~P;:'M-- I 


EXPANSION 
I 


usee· 
341 


eOARD) 
I 


641<. BYTES 
_____ 
-.J 


STATIC 


RAM 


12K 
DUAL 
PORT 
4I(·lOCAL 


DUAL 


PORT 


ACCESS 


CONTROL 


2481T 


SLAVE 


ADDRESS 


DECODE 


Interrupt Request Generation 


Listed 
in Table 
4 are the 
devices 
and 
functions 


supported 
by interrupts 
on the iSBC 88/45 AOCP 


board. All interrupt 
signals 
are brought 
to the inter· 


rupt jumper 
matrix. 
Any of the 23 interrupt 
sources 


are strapped 
to the appropriate 
8259A PIC request 


level. 
The PIC resolves 
requests 
according 
to the 


software 
selected 
mode and, if the interrupt 
is un· 


masked, 
issues 
an interrupt 
to the CPU. 


EPROM/RAM Expansion 


In addition 
to the on-board 
RAM, 
the 
iSBC 
88/45 


AOCP 
board 
proVides 
four 
28-pin 
JEOEC 
sockets 


for 
EPROM 
expansion. 
By using 
2764 
EPROMs, 
the board 
has 32K bytes of program 
storage. 
Three 


of the J EOEC standard 
sockets 
also support 
byte· 
wide 
static 
RAMs; 
uSing 
8K x 8 static 
RAMs 
pro· 


vides 
an additional 
24K bytes 
of RAM. 


Inserting 
the 
optional 
iSBC 
341 
MULTIMOOULE 


EPROM 
expansion 
board 
onto 
the 
iSBC 
88/45 


AOCP board provides 
four additional 
28-pin JEOEC 


sites. 
This 
expansion 
doubles 
the 
available 
pro· 


gram 
storage 
or extends 
the 
RAM 
capability 
by 


32K bytes. 


iSBX™ MUl TIMODUlE™ 
Expansion 


Two 
8-bit 
iSBX 
MULTIMOOULE 
connectors 
are 
provided 
on 
the 
iSBC 
88/45 
microcomputer. 


Through 
these 
connectors, 
additional 
iSBX func· 


tlons 
extend 
the 
I/O capability 
of the 
microcom· 


puter. 
The iSBX connectors 
proVide 
the necessary 


signals 
to interface 
to the local 
bus. 


In 
addition 
to 
specialized 
or 
custom 
deSigned 


iSBX 
boards, 
the customer 
has a broad 
range 
of 


Intel 
iSBC 
MUL TIMOOULEs 
available, 
Including 


parallel 
I/O, analog 
I/O, IEEE 488 GPIB, floppy 
disk, 


magnetic 
bubbles, 
video, 
and serial 
I/O boards. 


The serial 
1/0 MULTIMOOULE 
boards 
Include 
the 


iSBX 
351 (one 
ASYNC/SYNC 
serial 
channel) 
and 


the 
iSBX 
352 
(one 
HOLC/SOLC 
serial 
channel) 


boards. 
Adding 
two 
iSBX 
352 
MUL TIMOOULE 


boards 
to the iSBC 88/45 AOCP provides 
a total 
of 


five HOLC/SOLC 
channels. 


The MUL TIBUS system 
is Intel's 
Industry 
standard 


microcomputer 
bus 
structure. 
Both 
8- and 
16-bit 


single 
board 
computers 
are 
supported 
on 
the 


MUL TIBUS 
structure 
with 
24 address 
and 
16 data 


lines. 
In addition 
to 
expanding 
functions 
con 


tained 
on a single 
board 
computer 
(e.g., memory 


and 
digital 
I/O), the 
MUL TIBUS 
structure 
allows 


very 
powerful 
distributed 
processing 
configura· 


tions 
with 
multiple 
processors, 
Intelligent 
slaves, 


and peripheral 
boards. 


Multimaster Capability 


The 
iSBC 
88/45 
AOCP 
board 
provides 
full 


MULTI BUS arbitration 
control 
10gic. This 
control 


Device 
Function 
No. of 
Interrupts 


MULTIBUS' 
Interface 
Select 1 interrupt 
from MULTIBUS' 
resident peripherals 
or other 
8 


CPU boards 


8273 HDLC/SDLC 
Transmit buffer empty and receive buffer full 
2 
Controller 
-- 


8274 HDLC/SDLC 
Software examines register for status of communication 
operation 
1 
SYNC/ASYNC Controller 


8254·Timer 
Counter 2 of both PIT deVices 
2 


iSBXTMConnectors 
Function 
determined 
by iSBXTMMULTIMODULeM 
Board (2 inter- 
4 
rupts per socket) 


Bus Fail Safe Timer 
Indicates 
MULTIBUS' 
addressed 
deVice has not responded 
to 
1 
command within 4 msec 
.- 


Power Line Clock 
Source of 60 MHz signal from power supply 
1 


Bus Flag Interrupt 
Flag interrupt 
in byte location 
1000H Signals board reset or data 
2 


handling request 


iSBC' 337 Board 
Numeric Data Processor generated status information 
1 


8237A·5 
Signals end of 8237 DMA operation 
1 


logic allows 
up to three iSBC 88/45 ADCP boards 
or other bus masters, 
including 
iSBC 80 and iSBC 
86 family 
boards to share the system 
bus uSing a 
serial 
(daisy 
chain) 
priority 
scheme. 
By using 
an 
external 
parallel 
priority 
decoder, 
the MULTISUS 
system 
bus 
could 
be 
shared 
among 
sixteen 
masters. 


The Intel standard 
MUL T1BUS Interprocessor 
Pro- 


tocol 
(MIP) software, 
implemented 
as the 
Intel 
iMMX 800 package for ,RMX 80, IRMX 86, and iRMX 
88 Real-Time 
Executives, 
fully 
supports 
multiple 
8-and 16-bit distributed 
processor 
functions. 
The 
software 
manages 
the message 
passing 
protocol 
/ 


between 
microprocessors. 


System Development Capabilities 


The application 
development 
cycle 
for an iSSC 
88/45 
ADCP 
board 
is 
reduced 
and 
simplified 
through 
the usage of several Intel tools. The tools 
include 
the Intellec 
Series 
Microcomputer 
Devel- 


opment 
System, 
the 
ICE-88 In-Circuit 
Emulator, 


the ISSC 957B debug 
monitor 
software, 
and the 


iRMX 86 and iRMX 88 run-time 
support 
packages. 


The Intellec 
Series 
Microcomputer 
Development 
System 
offers 
a complete 
development 
environ- 


ment for the ISBC 88/45 software. 
In additIOn to the 
operating 
system, assembler, 
utilities 
and applica- 


tion debugger 
features 
provided 
with the system, 


the 
user 
optionally 
can 
utilize 
higher-level 
lan- 
guages 
like PUM, PASCAL, and FORTRAN. 


The ICE-88 In-Circuit 
Emulator 
provides 
a link be- 


tween 
the 
Intellec 
system 
and 
the 
target 
,SBC 


88/45-based 
system 
for code 
loading 
and execu- 


tion. 
The 
ICE-88 package 
assists 
the 
developer 
with 
the debugging 
and system 
integrating 
pro- 
cesses. 


Run·Time Building Blocks 


Intel 
offers 
run-time 
foundation 
software 
to sup- 
port applications 
which 
range 
from 
general 
pur- 


pose to high-performance 
solutions. 
The ,RMX 88 


Real-time 
Multitasking 
Executive 
provides 
a multi- 


tasking 
structure 
which 
includes 
task scheduling, 


task management, 
intertask 
communications, 
and 
interrupt 
servicing 
for high-performance 
applica- 
tions. 
The highly 
configurable 
modules 
make the 


system 
tailoring 
job easier whether 
one uses the 
compact 
executive 
or the complete 
executive 
with 


its variety of peripheral 
devices 
supported. 


The iRMX 86 Operating 
System 
provides 
a very 


rich set of features 
and options 
to support 
sophis- 


ticated 
applications 
solutions. 
In addilion 
to sup- 


porting 
real-time 
requirements. 
the iRMX 86 Oper- 
ating 
System 
has 
a powerful. 
but 
easy-to-use 


human interface. 
When added to the sophisticated 
I/O system, the iRMX 86 Operating 
System is readi- 


ly extended 
to support 
assembler, 
PLlM, PASCAL 


and 
FORTRAN 
software 
development 
environ- 


ments. The modular 
building 
block software 
lends 


Itself well to customized 
application 
solutions. 


Instruction 
- 
8, 16,24, or 32 bits 


Data - 
8 or 16 bits 


System Clock 


8 MHz - 
± 0.1% 


NOTE: 
Jumper 
selectable 
tor 
4 MHz 
operation 
with 
ISBC 
337 
Numeric 
Data 
Processor 
module 
or ICE·88 
product. 


Cycle Time 


Basic Instruction 
Cycle at 8.00 MHz - 
1.25 Jlsec, 


250 nsec (assumes 
instruction 
in the queue) 


NOTE: 
BasIc 
Instruction 
cycle 
IS defined 
as the fastest 
Instruc· 


tlon 
time 
(I.e., two 
clock 
cycles). 


Memory Cycle Time 


RAM - 
500 nsec (no wait states) 


EPROM - 
jumper selectable 
from 500 nsec to 625 
nsec_ 


K Bytes 
Hex Address 
Range 


16 (total) 
OOOO·3FFF 


12 (dual-ported) 
1000·3FFF 


• Four 
ISBC 
88/45 
EPROM 
sockets 
support 
JEDEC 
24128·pm 
standard 
EPROMs 
and RAMs 
(3 sockets). 
ISSC 341 (4 sockets) 


Temperature 
- 
0-55°C, free moving air across the 


base board and MUL TIMODULE 
board 


Physical Characteristics 


Width 
- 
30.48 cm (12.00 in) 


Length 
- 
17.15 cm (6.75 In) 


Height 
1.50 em (0.59 in) 


Weight 
6.20 gm (22 oz) 


Device 
Total 
Hex Address 
K Bytes 
Range 


2716 
8 
FEOOO-FFFFF 


2732A 
16 
FCOOO-FFFFF 


2764 
32 
F8000-FFFFF 


27128 
64 
FOOOO-FFFFF 


With 
optional 
iSBC'" 341 MUL TIMODULfTM 
EPROM 
- 


Device 
Total 
Hex Address 
K Bytes 
Range 


2716 
16 
FCOOO-FFFFF 


2732A 
32 
F8000-FFFFF 


2764 
64 
FOOOO-FFFFF 


27128 
128 
EOOOO-FFFFF 


• Four iSBC 88/45 EPROM sockets 
support 
JEDEC 24/28-pin 


standard 
EPROMs and RAMs (3 sockets); 
iSBC 341 sGckets 


also support 
EPROMs and RAMs. 


Interfaces 


iSBXTM Bus - 
All signals 
TTL compatible 


Serial 
RS232C Signals 
- 


CTS 
CLEAR 
TO SEND 


DSR 
DATA SET READY 


DTE TXC 
TRANSMIT 
CLOCK 


DTR 
DATA TERMINAL 
READY 


FG 
FRAME 
GROUND 


RTS 
REQUEST 
TO SEND 


RXC 
RECEIVE 
CLOCK 


RXD 
RECEIVE 
DATA 


SG 
SIGNAL 
GROUND 


TXD 
TRANSMIT 
DATA 


Serial 
RS422A1449 Signals 
- 


CS 
CLEAR 
TO SEND 


DM 
DATA MODE 
RC 
RECEIVE 
COMMON 


RD 
RECEIVE 
DATA 


RS 
REQUEST 
TO SEND 


RT 
RECEIVE 
TIMING 


SC 
SEND COMMON 


SD 
SEND 
DATA 


SG 
SIGNAL 
GROUND 


TR 
TERMINAL 
READY 


TT 
TERMINAL 
TIMING 


Electrical Characteristics 


DC Power 
Dissipation 
- 
28.3 Watts 


DC Power 
Requirements 
- 


Current 
Requirements 


Configuration 
(all voltages 
~ 5%) 


+5V 
+ 12V 
-12V 


without 
EPROM' 
5.1A 
20 mA 
20 mA 


with 
8K EPROM 
+0.14A 
(using 
2716) 
- 
- 


with 
16K EPROM 
+ 0.20A 
- 
- 
(using 2732A) 


with 
32K EPROM 
+ 0.24A 
(using 
2764) 
- 
- 


with 
64K 
EPROM 
+ 0.24A 
(using 
27128) 
- 
- 


NOTE 1: AS SHIPPED - no EPROMs in sockets, 
no iSBC 341 


module. 
Configuration 
Includes 
terminators 
for two 


RS422A/449 and one RS232C channels. 


Channel 
Device 
Supported 
Max. Baud 


Interface 
Rate 


A 
8274' 
RS442A1449 
800K 
SOLC/HOLC 


RS232C 
125K 
Synchronous 


CCITTV.24 
50K 
Asynchronous 


B 
8274 
RS232C 
125K 
Synchronous2 


CCITTV.24 
50K 
Asynchronous 


C 
82733 
RS442A/449 
64K 
SOLC/HOLC3 


RS232C 
9.6K 
SELF CLOCKING 


CCITTV.24 


NOTES: 
1. 8274 supports HDLC/SDLC/SYNC/ASYNC 
multlprotocol 
2. Exceed RS232C/CCITT V.24 rating of 20K baud 
3. 8273 supports HDLC/SDLC 


8254 
Synchronous 
Asynchronous 


Timer 
Divide 
.;.16 
.;.32 
.;.64 


CountN 
K Baud 
K Baud 


10 
800 
50.0 
25.0 
12.5 


26 
300 
19.2 
96 
4.8 


31 
256 
16.1 
8.06 
4.03 


52 
154 
96 
48 
2.4 


104 
768 
4.8 
2.4 
12 


125 
64 
4.0 
2.0 
1.0 


143 
56 
3.5 
1.7 
.87 


167 
48 
3.0 
1.5 
.75 


417 
19.2 
- 
- 
- 


833 
9.6 
- 
- 
- 


EQUATION 
8.000,000 
500K 
250K 
125K 


N 
tr tr tr 


Interlace 
Mode' 
MULTIMODULETM 
Cable 
Connector 
Edge Connector 


RS232C 
DTE 
26·pin',3M·3462·0001 
3M2·3349/25 
25·pin6,3M·3482·1000 


RS232C 
DCE 
26·pin',3M·3462-0001 
3M2·3349/25 
25·pin6,3M·3483·1000 


RS449 
DTE 
40·pin5,3M·3464·0001 
3M3·3349/37 
37·pin',3M·3502-1000 


RS449 
DCE 
40·pin5, 
3M·3464·0001 
3M3·3349/37 
37·pin',3M·3503·1000 


NOTES: 
1. DTE - 
Data Terminal Equipment mode (male connector); DCE - 
Data Circuit Equipment mode (female connector) requires line 


swaps. 
2. Cable IS tapered at one end to fit the 3M·3462 connector. 
3 
Cable IS tapered to fit 3M-3464 connector. 


4. Pin 26 of the edge connector is not connected to the flat cable. 
5. Pins 38, 39, and 40 of the edge connector are not connected to the flat cable. 
6. May be used with the cable housing 3M-3485-1000. 
7. Cable housing 3M·3485·4000may be used with·the connector. 


Reference Manual 


143824 
- 
iSBC 88/45 Advanced 
Data Communica· 


tions 
Processor 
Board Hardware 
Reference 
Man· 


ual (not supplied). 


Reference 
manuals 
may be ordered 
from any Intel 


sales representative, 
distributor 
office 
or from Intel 


Literature 
Department, 
3065 Bowers Avenue, Santa 


Clara, CA 95051 


Device 
Characteristic 
aty 
Installed 


1488 
RS232C 
3 
1 


1489 
'RS232C 
3 
1 


3486 
RS422A 
2 
2 


3487 
RS422A 
2 
2 


Part Number 


SBC 88/45 


Description 


8·bit 8088·based 
Single 
Board 


Computer 
with 3 HDLC/SDLC 


serial channels 


APPLICATION 
NOTE 


I. INTRODUCTION 


As the microcomputer system found its way into 
more and more demanding 
applications 
the need 
became clear for a new and innovative solution to 
the old problem of providing timely response to 
real world e~ents. This need was never clearer 
than 
in the 
field 
of communications 
where 


throughput 
and response 
time are the keys to 
success. The iSBC 544 Intelligent 
Communica· 


tions Controller (ICC) is the vanguard 
of a family 


of intelligent 
slave 
computers 
that 
provide 
a 
unique and powerful answer to the needs of the 
microcomputer 
user. 


This application note is intended to introduce the 
reader to the intelligent 
slave concept in general 
and the iSBC 544 board in particular. 
After a 
brief overview of the evolution of the concept and 
the 
features 
it provides, 
the 
hardware 
and 
software 
aspects 
of the controller 
are studied. 
Following 
this 
a summary 
of various 
system 
throughput 
tests 
is examined 
to evaluate 
the 
performance 
of the intelligent 
slave versus more 


traditional 
system architectures. 
We then study 


two example 
applications 
of the product 
and 
relate the earlier discussions 
to the real world. 


Finally, some system software is presented that 
handles 
all data transfer 
duties between master 
single board computers and intelligent slaves on 
the 
MULTIBUS 
system 
bus. 
More detailed 
information on many of the topics covered in this 
note can be found in the related 
publications 
listed in the front-piece. 


II. OVERVIEW 
Intelligent 
Slave Architecture 


Over 
the 
years, 
component 
technology 
has 
increased 
at a rapid 
pace going from discrete 
components (eg. transistors) 
to integrated circuits 


(eg. TTL devices) to programmable 
peripheral 
controllers 
(eg. Intel 8251A Universal 
Synchro- 
nous/ Asynchronous 
Receiver/Transmitter) 
to 
fully intelligent 
slave devices (eg. Intel 8041A 
Universal 
Peripheral 
Interface). At the system 
level the evolution followed a similar path using 
the increasing 
component 
technology 
to create 
more and more powerful system building blocks. 
The iSBC 508 I/O board used TTL logic to provide 
digital I/O expansion 
for iSBC computers. The 


iSBC 534 board took advantage 
of programmable 


LSI devices to provide a programmable 
commu- 


nications expansion board. Now, with the advent 
of the 
iSBC 544 Intelligent 
Communications 


Controller, 
a new level of system 
capability 
is 


made possible 
with the fully intelligent 
slave 


controller. 


The cornerstone of the intelligent slave architec- 
ture is the dual port memory: Through the use of 
this shared 
memory space, a fast and efficient 


protocol can be established 
to allow for coopera- 


tion 
between 
master 
and intelligent 
slave 
in 


solving the needs of the application 
system. -In 


addition to the shared memory, the CPU on the 
intelligent 
slave also has some local RAM and 
local PROM storage for programs. 
By using this 


architecture 
the advantages 
of multiprocessing 


and Direct Memory Access (DMA) controllers are 
blended together. 
Unlike 
DMA controllers, 
the 
intelligent slave works totally within its own data 
space. Therefore, it is not affected by bus traffic 
nor does it add to this traffic. And, since the on- 
board CPU gets its instructions 
from local PROM 
instead 
of predefined hard-wired logic or micro- 


code, the user has total flexibility in defining the 
functions the intelligent slave will assume in the 
overall system. 


Although 
the contents 
of an intelligent 
slave 
make 
it look very 
similar 
to a single 
board 
computer, the assumption 
of the slave role pro- 


vides a distinct advantage. 
By performing duties 
for a master 
single board computer, the slave 
relieves the master of low-level processing duties 
and at the same time is itself relieved of system 
responsibilities. 


In order to position the iSBC 544 product and 
outline what features it brings to the application 
system 
it is necessary 
to define the functions 
involved 
with communicating 
data. 
The three 
main functional 
divisions are illustrated 
in Fig- 


ure 1. At the lowest level the physical intercon- 
nection is maintained. 
This level involves such 
standards 
as RS232C which defines the require- 
ments for transmitting 
bits from point to point. 


The data transmission 
level involves the transfer 
of bytes and/or 
blocks of data from devices to 
computers 
and from node to node in computer 
networks. 
The hardware 
dependent 
software 
such as interrupt 
service and device polling is 


I I I I 


I I I I 


part of this level as are handlers 
for standard 


protocols such as SDLC, HDLC, Bisync and X.25 
or special purpose schemes and custom protocols. 


The highest level performs the actual processing 
of the data and calls upon the lower levels to move 
the data 
from place to place. The application 


software resides at this level as do some high level 
software functions such as program to program 
and process to process communications packages. 


Now that we have a map of system functions to 
guide us, it is possible to gain an understanding 
of 


the usefulness 
of a product like the iSBC 544 


Intelligent 
Communications 
Controller. 
If an 


iSBC 534 board (which contains 
four USART 


devices) was included to handle the expansion of 
serial 
I/O 
capacity 
the 
mapping 
of system 


functions would look like that shown in Figure 
2. The four USARTs on the board would handle 
the physical interconnection but due to the lack of 
intelligence on the board the master CPU would 
be burdened with all of the data transmission 
duties in addition to its real duty, data processing. 


When an iSBC 544 board is used in the system, 
the mapping of system functions is as sRown in 
Figure 
3. The physical 
interconnection 
is still 


handled by the USARTs on the board but now the 
on-board CPU can be programmed to assume the 
data 
transmission 
duties. With 
an 
intelligent 


slave in the system, the master CPU is freed to 
concentrate on the data processing functions and 
the end result is that each function in the system 
is handled in the most efficient manner possible. 
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2. Mapping 
of System 
Functions 
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Figure 
3. Mapping 
of System 
Functions 
with 


ISBC 
544 Board 


The iSBC 544 Board 


The 
iSBC 
544 
Intelligent 
Communications 


Controller contains: 


• An Intel 8085A CPU operating 
at 2.76 MHz. 


• Sockets for up to 8K bytes of read only memory 


(user can choose Intel 
2716, 2316E or 2732 


devices). 


• 16K bytes 
of dynamic, 
dual 
port Random 


Access Memory (RAM). 


• 256 bytes of static local RAM. 


• Four Intel 8251A USARTs with programmable 


baud rates. 


• Two Intel 8253 Programmable 
Interval Timers. 


• Intel 
8155 parallel 
interface 
providing 
22 


parallel 
lIO 
lines 
and 
one 14 bit interval 


timer. 
Various 
input 
and 
output 
lines 
are 


dedicated to provide an interface to a Bell 801 
or equivalent 
Automatic 
Call Unit (ACU). 


• 8259A Priority 
Interrupt 
Controller. 


III. 
HARDWARE 
CONSIDERATIONS 


This section of the application 
note will focus on 


the 
iSBC 
544 hardware 
and 
will outline 
the 


features 
of the board and its uses. Appendix A 


contains 
simplified logic diagrams 
of the iSBC 


544 board which can be referenced in the follow- 
ing discussions. 


Two Mode Operation 


The iSBC 544 board is capable of operating in one 
of two modes; 1) intelligent 
slave and 2) stand- 


alone communications 
computer. The mode can 


either be set with a switch or it can be "toggled" 
via a software driven flip-flop on the board. In 
the intelligent 
slave mode the CPU on the iSBC 
544 board operates 
strictly 
within 
its on-board 


resources. Communications 
with 8-bit and 16":bit 


master 
single board computers 
is accomplished 


through 
the dual port memory. 
Since the on- 
board CPU executes code out of its local PROM 
program 
storage 
the system designer is free to 


define which functions 
the slave will aSljume in 


the system 
design. 
As discussed 
earlier, 
this 


could 
include 
all or part 
of the 
system 
data 


transmission 
duties or could involve application 


specific duties such as terminal 
format control, 


code conversion 
or terminal 
input editing. 


In the stand-alone 
mode, the logic on the board 


disables 
off board access to the dual port RAM 


and the bus buffers are used to allow the on-board 
CPU to access expansion memory and lIO on the 
MULTIBUS system bus. In this mode the iSBC 
544 board drives the bus busy (BUSY/) control 
line active 
disallowing 
any 
other 
bus master 


access to the bus. The stand-alone 
communica- 


tions computer is capable of performing all of the 
functions 
of the applications 
system. Referring 


once again to the diagram 
of the functions 
of a 


communication 
system, the stand-alone 
commu- 


nications 
computer, 
with 
or without 
system 


expansion, 
is responsible 
for all data transmis- 


sion and data 
processing 
functions. 
In small 


applications 
requiring 
multiple 
serial lines the 


stand-alone 
iSBC 544 controller is a perfect fit. 


In very special 
circumstances 
it is possible to 


share the system bus by toggling the mode set 
flip-flop between master and slave mode. Figure 4 


Figure 
4. ISBC 544 Controller 
Running 
ISBC 204 


Disk Controller 


shows 
the 
flow chart 
for a routine 
(code in 
Appendix 
B) that 
makes 
use of the "software 
switch" to operate an iSBC 204 Diskette Control- 
ler. Using the iSBC 544 board in a system with 
DMA devices is not recommended except in cases 
where DMA accesses 
are short 
and relatively 
rare. The use of the CPU for the handling of other 
system 
devices 
could 
seriously 
degrade 
its 
performance 
as a communications 
controller. 


However, 
this 
capability 
could be extremely 
useful in a system such as a small message store 
and forward where the disk traffic is not heavy 
and including a CPU card just to handle the disk 
would be wasteful. 
Use of the "software switch" 


to share the bus with another iSBC CPU is not 
advised because of the amount of protocol that 
would be required to keep the CPUs from interfer- 
ing with each other on the bus. 


Dual Port RAM 


Figure 5 illustrates 
the dual port RAM memory 
array on the iSBC 544 card. A triple bus architec- 
ture 
is used 
to allow 
other 
MULTI BUS bus 
masters 
access to the RAM on the intelligent 
slave. 
Both the 
on-board 
CPU's 
bus 
and the 
MULTIBUS system bus are connected to the dual 


port controller. From here the dual port bus is 
connected to the 16K of dynamic RAM memory. 
Memory transfer 
requests from either of the first 
two busses are handled by the dual port control 
logic with the on-board CPU being given priority 
if contention arises. The local CPU is favored so 
that it is not overly delayed in handling 
its time 
critical functions. 


The address mapping of the dual port memory on 
the iSBC 544 is diagrammed in Figure 6. The user 
can enable access from the MULTIBUS system 
bus to 0, 4K. 8K or all 16K of the RAM on each 
iSBC 544 board. 
The 
dual 
port 
control 
logic 
decodes the full 20-bit address 
and provides an 
8-bit data path to the bus. For these reasons the 
iSBC 544 board is compatible with 8080A, 8085A 
and 8086 based single board computers. 
The user 
can also select the block of addresses 
on the 
system 
bus to which 
the iSBC 544 RAM will 
respond. 


MULTIBU$ 
isac 544 
SYSTEM 
ON·BOARD 
ADDRESS 
ADDRESS 
SPACE 
SPACE 


XFOOO 
FOOD 


xoooo 
EDoa 


xeooo 
DODO 


xeooo 
COOO 


xeooo 
BOOO 


XAOOO 
AOOO 


X9000 
9000 


X8000 


~ 


8000 


X7000 
7000 


X6000 
6000 


XSOOO 
5000 


X4QOO 
4000 


DEDICATED 
X3000 
STATIC 
RAM 
3000 


X2000 


ROM/PROM l 
----- 
2000 


X1QOO 
1000 


X 
ANY PAGE 
ADDRESS, 
0 TO F(HEX) 


When accessed by the on-board CPU, the dual 
port RAM always appears at 8000H. If the iSBC 
544 board is operating in the stand-alone compu- 
ter mode, the board is capable of generating 
the 


16-bit bus address supported by the 8085A CPU. 


Interrupt 
Structure 


The interrupt structure of the iSBC 544 controller 
is designed to handle the heavy load imposed by 
the inherent 
real-time nature of the communica- 


tions application. 
An 8259A Priority 
Interrupt 
Controller handles the four receiver and transmit- 
ter ready interrupts 
from the 8251A devices and 


provides vectored interrupts 
using one of many 
available 
priority 
schemes. 
In addition 
to the 
eight interrupt sources handled by the 8259 there 
are various others that can be connected directly 
to the vectored 
interrupt 
inputs 
on the 8085A 


(RST 
5.5, 6.5, 7.5 and TRAP). One interrupt 
is 
generated by the dual port control ~ogicwhenever 
a byte is written into the base address of the dual 
port memory by an offboard CPU. This interrupt, 
the flag interrupt, 
is cleared automatically 
when 


the on-board CPU reads the byte and is useful 
when designing 
a master-slave 
protocol since it 
provides a unique interrupt 
to each slave in the 
system. 


If the 8251A devices are used to interface 
to 


modems the loss of carrier 
and ring indicator 


interrupts 
from all four channels 
need to be 
connected to 8085A interrupt request inputs. This 
is accomplished 
with four input OR gates tying 


the eight sources into RST 6.5. The ring indicator 
and carrier 
detect lines can also be monitored 


through 
a parallel 110 port. This port would be 
read in a polled system to determine 
status 
or 


could be used along with the OR-tied interrupts to 
determine which channel is sourcing the current 
interrupt. 


The remaining 
interrupt 
sources come from the 
extra timer/counters 
and from the MULTIBUS 
interrupt lines. In addition to receiving interrupts 
from 
the 
bus, 
the 
iSBC 
544 board 
has 
the 
capability 
of generating 
MULTIBUS interrupts 
using the Serial Output Data (SOD) line on the 
8085A CPU. 


Modem 
and Autocall 
Interface 


The iSBC 544 controller 
uses 8251A and 8155 
devices for interface to modems and an autocall 


unit respectively. All of the necessary handsha- 
king signals concerned with the modem interface 
are connected to the 8251A and the carrier detect 
and ring indicator 
signals, 
as previously 
men- 


tioned, can be connected to interrupt inputs. 
The 


8155 parallel ports are wired as shown in Figure 
7. All ofthe commonly used signals defined in the 
EIA 
RS-366 specification 
for interface 
to an 


autocall 
unit are provided. The software 
neces- 


sary 
for handling 
the ACU becomes a simple 


matter 
of responding 
to the ACU requests 
and 


sending 
out the BCD digits 
representing 
the 


number 
being dialed. In addition 
to the ACU 


interface, the 8155 monitors various signal states 
and provides software reset capabilities 
for the 


USARTs and some interrupts. 


IV. SOFTWARE 
CONSIDERATIONS 


Software for the iSBC 544 ICC falls into three 
main categories; 
device programming, 
master- 


slave protocols, 
and communications 
support 
Each 
of these 
three 
topics 
is covered 
in the 


following section with the aim of defining the 
software requirements 
and functions of the iSBC 


544 board. 


Device 
Programming 


The main sources of the power and flexibility of 
this product are the programmable 
LSI devices on 
the board. The first duty ofthe on-board software 
is programming 
these 
devices 
to handle 
the 


specific task at hand. To start with, the 8251A 
USART can be programmed 
for synchronous 'or 
asynchronous 
operation. 
In synchronous 
mode 


the user specifies even, odd or no parity and either 
external or internal 
sync detect with one or two 


sync characters. 
In the asynchronous 
mode the 


programmer 
selects 
the parity, 
the character 


length (5, 6, 7 or 8 data bits), the framing control 
(1, 11/2 or 2 stop bits) and the baud rate scaling 
factor (input clock frequency divided by 1, 16 or 
64). 


The 8253 Programmable 
Interval Timers provide 


the 
receiver 
and 
transmitter 
clocks 
for the 


USARTs and, along with the 8251A baud rate 
scaling factor, are programmed by the software to 
provide the desired communications 
frequency. In 
addition, 
two additional 
16 bit timers 
are left 


available to the applications 
programs to be used 


as event counters, real-time interrupts, 
etc. 


The 8259A Priority 
Interrupt 
Controller 
is 


programmed 
to vector all interrupts 
through 
a 


jump table in memory. Also, the device provides 
software 
selectable 
priority 
schemes 
and an 


interrupt mask register for sophisticated interrupt 
management 
designs. 


Last, 
but not least, 
the 8155 Programmable 


Peripheral 
Interface 
provides various software 


controlled input and output ports as discussed in 
previous sections. One specific point to remember 
is that the power on state of the 8155 clamps the 
reset signal to the USARTs active and must be 
removed by programming 
the 8155 before com- 


munications 
can begin. 


Master-Slave 
Protocols 


If an application 
system 
is visualized 
at the 


highest 
level it appears to be a computer with 


various inputs 
and outputs as depicted in Figure 


8a. If this computer is broken down into a master 
CPU and one or more intelligent 
slaves, great 


increases 
in efficiency and system throughput 


can be realized by distributing the duties between 
the CPU s (Figure 
8b). Once this 
split is per- 


formed, some well defined means of communica- 
tion between 
master 
and 
slaves 
needs 
to be 


defined so that the processes that execute on the 
different machines can cooperate. This means of 
communication 
takes 
the 
form 
of a protocol 
followed by both master and slave. 


INPUTS 


APPLICATION 


SYSTEM 


OUTPUTS 


The intelligent slave architecture was designed to 
simplify 
the 
development 
of the necessary 


protocol. The shared 
memory space in the dual 


port 
RAM provides 
a large 
communications 


buffer area where data 
and commands 
can be 


transferred 
using normal memory transfers. Data 


structures 
of any needed complexity can be built 


in this memory area and accessed by both master 
and 
slave. 
The flag interrupt 
can be used to 


provide a unique synchronization 
signal from a 


master to a given slave. In addition, the MULTI- 
BUS interrupt 
lines can be used to provide extra 


signals in both directions. As we shall see in the 
system software section, these basic tools can be 
utilized to design a general purpose data transfer 
mechanism 
which 
isolates 
the 
applications 


processes 
from 
the worries 
of protocols 
and 


synchronization. 


Communications 
Support 


The previous software topics dealt mainly with 
the system overhead that must be handled by the 
communications 
processor. The larger and more 


important 
duty of the CPU is dealing with the 


application 
at hand-communications. 


When configured as an intelligent 
slave to some 


master 
iSBC CPU board, the iSBC 544 board 


works to offload the master of communications 
related functions 
and at the same time is itself 


relieved of a major share of the system overhead 
and can be tuned to provide thl! highest possible 
throughput. 
With this 
combination, 
more com- 


plex 
applications 
can 
be tackled 
where 
the 


number 
of lines 
and the line frequencies 
are 


greatly 
increased. 
Multiple 
systems 
can 
be 


employed to provide a network facility with the 
iSBC 
544 board 
now handling 
the 
network 


protocol 
in addition 
to its other 
duties. 
The 


architecture of the iSBC 544 controller is designed 
to simplify 
the user's 
software 
development 


process. The board can be programmed to handle 
many possible data transmission 
functions from 


simple line protocols to terminal 
control to link 


protocols and all the way up to network protocols. 


In the stand-alone mode, the iSBC 544 board can 
assume 
total responsibility 
for the application. 
This can be done with on-board resources only or 
can include the support of offboard expansion like 
the iSBC 534 four channel serial controller. Appli- 


cations of the stand-alone controller could include 
cluster 
controllers, 
peripherals 
managers, 
line 


concentrators 
or any other small system. 


v. THROUGHPUT 
ANALYSIS 


This section of the application 
note deals with 


studies 
that 
have 
been done to quantify 
the 


performance 
of the iSBC 544 board in both the 


stand-alone 
and intelligent 
slave modes. After 


describing 
the various 
test configurations 
and 


assumptions 
the 
data 
will 
be presented 
in 


graphical form and analyzed. 
The graphical data 


can be found in Appendix C. 


Stand 
Alone 
Throughput 


The first two tests 
were run to determine 
the 


absolute 
best case throughput 
of. the iSBC 544 


board configured as a stand-alone computer. Fig- 
ure 9a shows the iSBC 544 controller continuously 
outputting 
data 
from four buffers 
to the four 


USARTs. Figure 9b shows essentially 
the same 


setup with eight channels, 
four on the iSBC 544 


board 
and 
four on the iSBC 534 expansion 


card. In each configuration the 8251A was run in 
synchronous 
mode and the baud rate was incre- 


mented until the transmitter 
empty signal from 


the USARTs became active. Further increments 
of the baud rates 
would not have 
resulted 
in 


higher 
throughput 
since the CPU was already 


spending 100%of its available time responding to 
USART service requests. 


The maximum 
rate 
for the first 
configuration 


(iSBC 544 board 
only) 
was 32,311 baud 
per 


channel. 
When the iSBC 534 expansion 
board 


was added a rate of 12,186 baud per channel was 
achieved. The drop in baud rate was due to the 
extra processing required by the offboard logic 
(eg. reading 8259 interrupt controller on the iSBC 
534 board to determine which device is requesting 
service). 


It should be noted that the serial throughput tests 
were run with almost no overhead and no actual 
processing 
of the data 
involved. The reader 
is 


expected to apply information 
on the amount of 


overhead expected in each individual application. 
For instance, 
if the application 
code for a given 


system is expected to utilize approximately 
40%of 


the available CPU time and we wish to run four 


full duplex channels 
in asynchronous 
mode the 
estimate of maximum 
baud rate would take the 
following form. 


32,331 baud per channel - 
40% = 19,398.6 baud 


19,398.6 baud per channel synchronous 
x 10/8 


= 24,248.25 baud asynchronous 


24,248.25 baud per channel 
half duplex/2 
= 
12,124.125 full duplex 


Therefore, 
the maximum 
standard 
baud 
rate 
would be 9600 baud per channel 
in full duplex 
asynchronous 
mode. 


Intelligent 
Slave Throughput 


The remaining 
four configurations 
were set up to 
determine the effectiveness of the intelligent slave 
in the overall system. The general system config- 
uration 
is illustrated 
in Figure 
10. The boards 
surrounded 
by the box r~present 
the systems 
under 
test. The disk controller 
and two iSBC 
80/20 single board computers were active on the 
bus to simulate the normal bus traffic load in an 
application system. Various bus duty cycles were 
created using the computers and the disk control- 
ler to perform tasks 
that 
resulted 
in fixed bus 
utilization. 


Figure 10. General SYltem Configuration for 
Throughput Teltlng 


In each configuration a single full duplex channel 
was set up with the input provided by another 
CPU. Only those functions dealing with system 
overhead were included and the data measured 


reflected the amount 
of bus time, master 
CPU 


time 
and 
slave 
CPU 
time 
left 
available 
to 
applications 
oriented 
tasks. 
In each case this 
percentage of time available was measured as the 
baud rate was stepped up so that a graph could be 
constructed showing time available as a function 
of transmission 
speed. 


CPU free time was measured 
using a counting 
program running 
in the background. 
After each 
USART interrupt 
the counter 
was started. 
As 
interrupts 
froni other sources came in the count- 


ing 
was 
preempted 
and 
then 
resumed 
after 
servicing the interrupt. 
When the next USART 
interrupt 
occured, 
the counter 
contents 
were 
examined 
and if the value was lower than 
the 
stored value the current value became the stored 
value. After ten minutes 
the stored value was 
retrieved and used as an indicator 
of the worst 
case time available 
between interrupts. 


System bus utilization 
was measured 
using. the 
circuit shown in Figure 11. The voltage measured 
by the 
digital 
voltmeter 
represented 
a time 
average of the voltage at the output of the flip- 
flop. A calibration 
chart 
was created 
using 
a 
pulse generator 
to simulate 
various duty cycles 
and then 
this chart 
was used to measure 
bus 
activity while the test was running. 


Configuration 
1 is shown 
in Figure 
12. This 
system uses a typical method of communications 
expansion 
with 
the iSBC 80/30 
single 
board 
computer handling the lines directly via the serial 
I/O ports on the iSBC 534 110 controller board. 
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The second configuration 
(Figure 13) illustrates 


the performance of the traditional 
DMA control- 


ler approach. 
If the communications 
controller 


had DMA logic instead of a dual port memory and 
transferred 
data directly into system memory the 


performance 
would be as observed in this test. 


In configuration 3 (Figure 14)the iSBC 544 board 
was used in the intelligent 
slave mode. This 


configuration 
differs 
from the second in that 
memory transfers 
involved 
only local memory 
and 
bus 
access 
was 
not 
requir2d 
on a per 
character 
basis. 


The fourth 
and final 
configur'ation 
sought 
to 
identify 
the loading that 
additional 
intelligent 
slave controllers would impose on master 
CPU 
time and bus free time. Figure 
15 shows the 
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configuration 
with two iSBC 544 boards execut- 


ing identical programs. 
. 


The graphical 
presentation 
of the results is split 


into two sections. The first three graphs (Graph 1 
through Graph 3) show the relationship 
between 
baud rates and the master CPU, system bus, and 
slave CPU utilization. 
All of these results 
are 
based upon tests with 30%induced bus traffic (i.e., 
the two iSBC 80/20 computers and the iSBC 204 
disk controller were active.) 


In graph 4, processor free time is graphed 
as a 


function of bus traffic. The processor in this case 
is the one actually involved with the data on a per 
character 
basis (i.e., iSBC 80/30 board in con- 
figuration 
1, iSBC 80/30 board simulating 
DMA 
Controller in configuration 2, and iSBC 544 board 
in configuration 
3). 


Finally, graph 5 illustrates 
the maximum attain- 
able baud rate for each configuration 
as the bus 
traffic is increased. 


All of the graphs 
identify 
the relative 
perfor- 
mance 
difference 
between 
the configurations. 


Absolute numbers 
are not presented 
due to the 


fact 
that 
the 
overhead 
imposed 
by the test 
software affects the CPU time being measured. 
Since the overhead applies equally to all config- 
urations, the relative performance indications are 
valid. 


Based upon the data presented, the DMA control- 
ler and intelligent slave use 3 times less CPU time 
than 
an 110 controller. 
Also, 
the iSBC 544 


intelligent 
slave generates 
12% and 6% less bus 
traffic than the 110 controller and DMA control- 
ler respectively. 
Finally, the intelligent slave uses 
8%less slave CPU time than the DMA controller 
approach. 


The earlier discussion that dealt with the intelli- 
gent 
slave 
architecture 
pointed 
out that 
the 
distribution 
of intelligence 
would offload 
the 
master 
CPU so that 
it would retain 
sufficient 
processing 
power for the actual 
application, 
whatever that may be. In addition, it was stated 
that the assumption of the slave role would relieve 
the slave CPU of system 
overhead 
and at the 
same time reduce system bus traffic. All of these 
assumptions 
are supported by the results of the 
testing presented here. 


The second set of graphs 
identify the effects of 
bus traffic 
on the performance 
of the various 
components of the system,. The main observation 
to be made in this sequence is the drop in CPU 
free times and maximum baud rates that occurs 
when the bus gets busy. This effect is observable 
in the communications 
processor free time when 
the 
iSBC 534 expansion 
board 
or the 
DMA 
controller 
configuration 
is used. No effect is 
evident in the configuration 
with an iSBC 544 


board. 


The cause of this 
effect is the amount 
of bus 


access required by each configuration to move the 
characters 
from 
the USART 
to or from 
the 


buffer. With an iSBC 534 board the master CPU 
receives 
an interrupt, 
polls the offboard 
8259 


interrupt controller, reads in a character, 
stores it 


in system memory and sends an end of interrupt 
command 
to the offboard 
interrupt 
controller. 


When the iSBC 80/30 
computer 
receives 
an 


interrupt 
all processing 
is performed 
onboard 
until a bus access is required to move the data 
byte fromlto memory. In the case of the intelli- 
gent 
slave, 
all processing 
for a character 
is 


performed 
onboard. 
Thus, 
as the system 
bus 


becomes very fully utilized, the delays encounter- 
ed in receiving 
bus 
access 
by the first 
two 


configurations 
become significant. 


The fourth configuration, which was set up to test 
the effects 
of adding 
more intelligent 
slaves, 


shows that 
extra 
slaves 
cause no appreciable 
increase in system load. All of the data points for 
two slaves were identical 
to the points for one 


slave in graphs 
1 through 
5. 


VI. APPLICATION 
EXAMPLES 


A Distributed 
Control 
System 


The potential 
applications 
for a product like the 


iSBC 544 communications 
controller are almost 


unlimited 
and not restricted 
to the traditional 


Data Communications 
market. 
The first applica- 


tion example that is studied concerns industrial 
automation. 
Due to the fact that 
the system is 


distributed 
and requires a generalized 
network, 


the iSBC 544 board is a natural prospect to handle 
the communication 
links between 
the various 


nodes in the system. 


Design 
Requirements 


The system to be designed is intended to provide 
the framework for a family of distributed 
control 


systems where the configurations 
and the objects 


to be controlled vary from system to system. Fig- 
ure 16 shows the general picture of the system. 


Figure 16. General 
Diagram 
of Distributed 


Control 
System 


The host is responsible for providing supervisory 
control 
and a high-level 
human 
interface. 
The 


system can be expanded 
as shown in Figure 17 


where the controllers 
attached 
to the host are 


replaced 
by intermediate 
nodes which contain 
controllers 
or other nodes. 
This process can be 


continued 
as far as is necessary 
to provide the 


needed number of controllers. 
Each controller in 


the diagram 
represents 
a localized 
closed loop 
control 
system 
that 
is tailored 
to the specific 
application. 


The following system requirements need to be met 
by the computer network: 


• The host CPU must have sufficient computa- 


tional 
power to handle 
the human 
interface, 


mass storage management, 
supervisory control 
calculations 
and network control. 


• The host CPU must not be overly burdened by 


low-level communications 
functions 
if it is to 


handle the other duties assigned 
to it. 


• Node controllers must be capable of handling 8 


medium 
speed lines 
and 
also modems 
and 
autocall 
units since the nodes or controllers 


attached 
may be remote. 


• The message 
transmission 
format 
must be 


independent 
of the configuration 
and end 
application. 
The nodes in the network must be 


capable of passing through messages with and 
without interpreting 
the contained 
data. 


• The system must be capable of auto-configura- 


tion (since the network configuration is tailored 
to the specific application, 
the host must be 


able to automatically 
determine 
the setup at 


power on). 


• Each node controller is responsible 
for verify- 


ing the integrity 
of the nodes attached. 


System 
Configuration 


Based upon the design criteria 
and the bench- 


mark information 
the chosen configuration 
uses 


an iSBC 86/12 Single Board Computer as the host 
with an iSBC 544 intelligent 
slave handling 
the 


communications 
load for the CPU. The USART 


on the CPU board will talk to the local terminal 
and an iSBC 206 Hard Disk Controller 
will be 


used to provide 
up to 40 Megabytes 
of mass 


storage capacity. 


The requirements 
for the node controllers point to 


an iSBC 544 board configured as a stand-alone 
communications 
computer 
with 
an iSBC 534 


board as expansion 
to provide the necessary 
8 


lines. 
The throughput 
data 
indicated 
a raw 


throughput 
value of 12K baud on each channel. 


With the data rates expected being far below this, 
sufficient 
time will be left over for background 


functions. 
Thus, the software 
requirements 
for 


each node can all be met by the CPU on the iSBC 
544 board 
and the inclusion 
of an expansion 


board does not necessitate 
another 
iSBC compu- 


ter. 


A typical controller in the system would look like 
that shown in Figure 18. The iSBC CPU handles 
the local closed loop control, 
using parametric 


information 
sent from the host. This information 


would typically include .setpoints, tolerances and 
alarm limits. The serial channel on the CPU will 
be used to maintain 
the link to the next level in 


the network. 


Preliminary 
Design 


The message 
format 
that 
the system 
uses is 


shown in Figure 19. When multiple nested levels 
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of nodes are used the data area of the message 
contains 
command 
and address 
information 
for 


the next level down (Figure 20). Interpretation 
of 
the commands 
in a given message is done on an 
individual 
basis except for a set of system-wide 


commands (eg. IDENTIFY is a system command 
meaning 
respond with your ID code). The flexi- 
bility afforded by this scheme can be extremely 
useful in a system where the end applications 
and 
configurations 
may be quite diverse (eg. a node 


controller that is processing a transmit command 
may be the only one that knows that it is sending 
to another 
node via a phone line and thus 
it 


interprets 
the contained 
data 
differently 
than 


another 
node would). The level of intelligence 


and the ease of programming 
of the iSBC 544 


board make this generalized transmission 
scheme 


possible. 


The simplest 
means 
of auto-configuration 
re- 
quires each controller in the system to send an 
identity message to the nearest node. This node 
would know the logical address of the controller 
that 
sent the message 
and would attach 
this 
address to the message and retransmit 
it to the 
next level as illustrated in Figure 21. This process 
would be repeated until the host is reached and 
would contain, at this point, all necessary address 
information 
to reach the given controller. 


The human interface on the host would provide a 
mapping 
mechanism 
to attach 
meaningful 
symbolic 
names 
to the various 
nodes in the 
system. This labeling, along with the application 
specific control algorithms, 
make it possible to 
say something like "lower the temperature on the 
third 
floor 
to 68°F". 
The 
host 
breaks 
this 
information 
down into setpoints and tolerances, 


uses the map to determine the path to the node(s) 
responsible for the third floor and transmits 
the 
information 
through the network. 


Each node controller in the system has the added 
responsibility 
of verifying the integrity of all the 


nodes attached to it. This duty can be handled by 
periodic background 
commands issued from the 


host and propagated through the network. Each 
node is responsible 
for passing 
the command 


along and also polling the nodes attached 
to it 


and reporting back any error conditions. 


Summary 


Through the use of a powerful 16-bit iSBC Single 
Board 
Computer, 
various 
low-cost 8-bit 
iSBC 


CPUs and the iSBC 544 communications control- 
ler, a flexible and extensible distributed 
control 


system is easy to design. The dual nature of the 
iSBC 544 board provides both an intelligent front 
end to the host computer and a high-speed stand- 
along nodal concentrator. 
The ability to individ- 


ually customize the software on each controller 
provides for an easily expandable system design. 


Terminal 
Cluster Controller 


The second application 
example concerns itself 


with a terminal 
cluster controller. The system 


shown in Figure 22 uses a number of "dumb" 
terminals 
and makes them appear "intelligent" 


via a local microcomputer 
system. 
The local 


microcomputer interfaces 
with the operator and 


accesses a local data base to provide an inquiry 
and data entry service. When necessary, the local 
microcomputer is capable of calling the host via 
an autocall unit and exchanging information and 
updates to the data base. 


Design Criteria 


The terminal 
cluster 
controller 
must meet the 


following criteria: 


• Support 
must 
be provided 
for from four to 


sixteen operator terminals all running at rates 
up to 2400 baud. 


• Line editing on input must be provided (delete 


characters, 
delete lines and pause output). 


• Support for the terminals must be configurable 


in that certain stations 
may require different 


screen formats. 


• Support for an optional hard copy device must 


be allowed for. 


• A considerable amount of CPU free time must 


be available 
after the basic terminal facilities 


are included. This is due to the fact that the 
data base management 
software to be written 


to run on the master single board computer will 
be extensive. 


• Type ahead would be a desired feature since the 


processing on the master CPU after a line of 
input has been transmitted 
may cause a delay 


in responding 
and we would like to 'have the 


ability to continue entering input while waiting 
for the response. 


System 
Configuration 


The specific iSBC products needed to implement 
the system described are the iSBC 80/30 Single 
Board Computer with an iSBC 032 RAM Expan- 


sion Board, an iSBC 206 Hard Disk Controller 
a,nd one to four iSBC 544 Intelligent Communica- 
tions Expansion 
boards. Intel's 
RMX/80 
Real- 


Time Multitasking 
Executive 
will provide 
the 


basis for the software 
system and will include 


disk 
file support 
for the iSBC 206 controller 
through 
DFS/80. The full system configuration 


is illustrated 
in Figure 23. 


Figure 23. Terminal 
Cluster 
Controller 
System 


Configuration 


Preliminary Design 


The first design decision to be made involves the 
distribution 
of system 
functions. 
Due to the 
requirements 
for line-editing and type-ahead the 
software for processing characters input from the 
terminal 
keyboards 
will be somewhat 
lengthy. 
The standard 
terminal 
output 
handler 
will be 
very 
small 
but 
provisions 
for special 
screen 
format controls and/or hard copy devices must be 
allowed for. All of these requirements 
lead to the 
use of the iSBC 544 controller for all terminal 
functions. 
If the master CPU were burdened with 
all of these duties it would be unable to adequately 
perform 
its data 
base management 
functions. 
The fast CPU and 8K PROM capacity of the iSBC 
544 board will be more than adequate for the task' 
at hand. 


The throughput 
tests indicate 
that 
the loading 
imposed by expanding 
the number of terminals 
(and therefore the number of iSBC 544 boards) 
will not adversely affect the performance of the 
rest of the system. Master CPU free time and bus 
traffic 
data 
for two intelligent 
slaves 
in the 
system 
were identical 
to the numbers 
for one 
slave. Thus, since the iSBC 80/30 single board 
computer 
and the MULTIBUS system bus can 
handle 
one iSBC 544 controller 
they can also 
handle the maximum of four controllers that may 
be required by this application. 
The only observ- 
able effect will be caused by the load the extra 
operators impose on the data base software itself. 


The software needed for the iSBC 544 board is 
now defined and divided into three major pieces; a 
terminal input handler, a terminal output handler 
and system 
software 
to support 
the handlers. 
Since the input and output handlers are invoked 
via USART interrupts, 
all that need be done is to 
write a single routine for each handler and have it 
talk to all of the devices on the board. This can be 
accomplished 
by vectoring the proper interrupts 
to the entry point of the routine and then polling 
the 8259A interrupt controller to determine which 
device needs servicing. 


The standard 
terminal 
input handler 
needs to 
read in the available character from the USART, 


check it to see ifit is a special command character 
and, if not, store it into a buffer. If a command 
character is encountered, the handler will respond 
by performing 
the appropriate 
operation. 


The standard 
terminal 
output 
handler 
simply 
takes characters 
out of a buffer upon interrupt 
from 
the transmitter 
and 
sends 
them 
to the 
appropriate USART. If a different output handler 
needs to be substituted for a special terminal or a 
hard copy device, a new routine can be included 
by modifying the interrupt 
vector address in the 
8259A jump table. 


Since 
the RMX/80 
Real-Time 
Multitasking 
Executive is being utilized on the master CPU it is 
desirable 
to create an RMX/80 handler 
for the 
iSBC 544 boards 
that 
accepts 
and 
processes 
normal 
terminal 
handler 
request 
messages. 
In 
this 
manner, 
application 
tasks 
that 
formerly 
communicated with the on-board USART via the 
RMX/80 Terminal Handler can be made to talk to 
one of the devices on the iSBC 544 board by 
simply changing the address of an exchange. The 
following paragraphs, 
as well as paragraphs 
in 
the section on system software, assume a know- 
ledge of the RMX/80 Real-Time Executive. This 
knowledge is not necessary to use the information 
contained 
in this 
application 
note. Interested 
readers 
are referred 
to the RMX/80 references 
listed in the front-piece. 


Since this application 
can have from one to four 
iSBC 544 boards the RMX/80 driver will need to 
be configurable. 
A set of tasks 
and exchanges 
will be created for each terminal 
in the system. 


One task 
and 
exchange 
pair 
will accept 
and 
process terminal 
input request 
messages 
while 
another 
pair 
wi~l process 
terminal 
output 
re- 
quests. 


The remaining piece of software that is needed by 
this system will provide the means for getting 
commands 
and data 
between 
the master 
and 
intelligent slave. Since this is a common need in 
any system utilizing an intelligent 
slave we will 
develop a general 
purpose scheme that 
can be 
used 
by any 
application. 
In this 
manner, 
a 
routine such as the terminal input handler can be 
written without any concern for how it will get the 
data it is inputting to the master CPU; all it need 
do is call upon a standard 
routine to "transmit" 


the data. 
With these 
thoughts 
in mind, 
the 


following section discusses the system software 
developed for master-intelligent 
slave communi- 
cation. After the discussion 
of the system soft- 
ware we will revisit the software for the second 
application 
as an example of the use of the data 


transfer 
routines. 


In the earlier discussion of master-slave protocols, 
the notion was presented of developing a general 
purpose data transfer scheme which would enable 
the applications 
routines on both the slave and 


master to operate without concerning themselves 
with protocols and synchronization. 
This scheme 


can 
be implemented 
by designing 
a set of 


primitive 
routines 
to handle 
the data 
transfer 


activities. Thus, Figure 8b is expanded as shown 
in Figure 24 and the applications 
processes now 


call upon the primitives to handle the communica- 
tions between the master and the slave. 


Data 
Transfer 
Primitives 


The basic mechanism 
used by this implementa- 


tion of the primitives is a wraparound 
queue as 


shown 
in Figure 
25. Each 
8251A device has 


associated with it, in dual port memory, an input 
and an output queue each of which have a give 


Figure 25. Wrap-around Queue Used by Data 


Transfer Primitives 


and a take pointer. The give pointer contains the 
address of the next location in the queue that is 
available 
for filling with data. The take pointer 
contains the address of the next byte in an output 
queue that 
has been filled and is available. 
A 
queue is empty when the give and take pointers 
are equal and it is full when the act of incre- 
menting the give pointer would make it equal to 
the take pointer. A wrap function is defined to 
' 


increment a pointer such that an increment past 
the bottom 
of the queue "wraps" 
the pointer 
around to the top of the queue. 


" 
DATA 
TRANSFER 
••••e--------~ 


PRIMITIVES 


The primitives all make use of a queue informa- 
tion 
block located 
at the base address 
of the 
slave's dual port memory (Figure 26). All pointer 
information 
is base relative to accommodate the 
needs 
of the 
two CPUs 
who have 
different 
memory maps. The two flag bytes carry informa- 
tion for master-slave 
and slave-master synchron- 
ization signals. 


The 
set of primitives 
provides 
two distinct 
methods 
of information 
transfer, 
line oriented 
and byte oriented. The line oriented primitives 
are listed in Table 1. Both get$line and send$line 
transfer 
information 
between 
the queues 
and 
buffers provided by the caller. The disadvantage 
of this scheme is the number of memory moves 
needed to transfer 
information. 
The advantages 
of the 
line 
oriented 
method 
are the relative 
efficiencies 
and the simplicity 
of the interface 
from the calling routine. 


The byte oriented primitives 
(Table 2) allow the 
calling routine to transfer 
data directly into and 
out of the queues. An example of the sequence for 
putting a character 
into a queue is illustrated 
in 
Figure 
27. The routine 
servicing 
the receiver 
ready interrupt calls next$space to get a pointer to 
the next available slot in the queue and then uses 
this pointer to transfer the data byte directly into 
the queue. The new$line, 
xmit, 
open$line 
and 
receive primitives are necessary since the global 
give and take pointers cannot be modified until 
all manipulations 
on the affected section of the 
queue are complete. If the pointers were modified 
continuously the routine gathering 
the data from 
the other side may see invalid data. 


~ 
LINES 
OF INPUT 
o 
WAITING 
FOR 
....--:> 
MASTER 
PROCESSOR 


Table 1 


Line Oriented Primitives 


Primitive 
Arguments 
Usege 


send$line 
Queue$token, buf$ptr. counf 
Inserts count characters into queue from buffer 
Returns: overflow 
If insufficient room available, overflow indicates how many would not fit 


gef$line 
Queue$token, buf$ptr, count 
Retrieves count characters from queue and puts them in buffer 
Returns: Actual 
Actual indicates how many were actually moved 


The remaining 
primitive routines deal with the 
general purpose needs of the application, software 
with regard to interrupts, initialization 
and status 
checking. A full list of these support routines is 
contained in Table 3. 


Ther~ are many features of this implementation 
and a few of them should be pointed out at this 
time. 
By defining 
a general 
purpose 
set of 
primitive routines to handle the data transfer, the 
actual means by which the bytes are transferred 
between slave and master is not visible to the 
calling 
routine. 
If the actual mechanism 
used 
needs to be altered the change will not affect the 
application software as long as the same external 
interface is maintained. 


Another 
important 
feature 
of the 
primitive 
routines is the fact that they do not interpret the 
bytes that are sent to them. Due to this fact, the 
applications 
routines are free to send commands 
and 
parameters 
interspersed 
with 
the actual 
data. As an example, the terminal driver on an 
iSBC 544 board might perform format 
control 
based upon table information. 
The master appli- 
cations 
software 
could use the data 
transfer 
primitives to transmit commands and parameters 
to the slave to update its format control informa- 
tion. Another advantage of the fact that the data 
is not interpreted 
is that 
it allows the calling 
routine to determine what data gets sent along. 
For 
instance, 
a specific 
terminal 
might 
be 
transmitting 
ASCII 
code while 
the master 


Table 2 


Byte Oriented Primitives 


Primitive 
Arguments 
Usage 


new$/ine 
Oueue$token 
Sets up a queue for byte oriented 
input. 


Returns: plr 
Plr returned 
points to the first available byte. 


next$space 
Oueue$token 
Increments 
the temporary 
give pointer to the next open space. 


Returns: ptr 
Plr returned either points to next byte or is zero specifying 
full queue. 


back$space 
Oueue$token 
Decrements 
temporary 
give pointer. 


Returns: ptr 
Ptr returned either points to byte or is unchanged 
indicating 
that the 


global give pointer was reached. 


xmit 
Oueue$token 
Closes off a line entered via byte mode by updating global give ptr to 


Returns: status 
equal temporary 
give ptr. 
Status is either "normal" 
or "null". 


open$/ine 
Oueue$token 
Opens up a line for byte oriented 
output. 
Returns: ptr 
Ptr returned either points to the next byte or is zero indicating 
an 
empty queue. 


next$char 
Oueue$token 
Increments 
temporary 
take pointer. 


Returns: ptr 
Ptr returned either points to next byte or is zero indicating 
an 


empty queue. 


receive 
Oueue$token 
Closes off a line retrieved 
in byte mode by updating 
global take 


Returns: status 
pOinter to equal temporary 
ptr. 
Status is either "normal" 
or "null". 


Table 3 


Support Routines 


Primitive 
Arguments 
. 
Usage 


get$status 
Oueue$token 
Returns status of queue. 
Possible values are "normal", 
"empty", 


Returns: status 
"full" 
and "null". 


set$interrupt 
Oueue$token, type 
Generates a slave - 
master or master - slave interrupt. 
Type code 0 
Returns: status 
is illegal and codes BH - 
OFH are reserved for use by the primitives. 


set$hand/er 
Oueue$token, handler$adr 
Inserts address into vector table used for handling 
interrupts 


Returns: status 
described 
above. 


s$init 
none 
Called from slave software to initialize. 


m$init 
none 
Called from master software to initialize. 


software is expecting EBCDIC. The routine on 
the slave can very easily perform the necessary 
code conversion before stuffing the data into a 
queue. 


Sample Slave Software 


Given the existence of the primitive routines the 
applications routines on the slave and master can 
deal with the specific duties of each device. The 
following 
paragraphs 
revisit 
the 
code from 


application example 2, first for the slave and then 
for the 
master. 
Full 
code listings 
for these 


programs 
can be found in Appendix D. 


The flowchart 
for the terminal 
input handler 
resident on the iSBC 544 board is shown in Figure 
28. Support is provided for deleting 
characters 


(Rubout), deleting lines (control-X), pausing and 
resuming 
output (control-S and control-Q) 
and 


terminating 
lines (escape and carriage 
return). 
The sections of code reproduced below use this 
terminal input handler to present an example of 
the use of the data transfer primitives to enter and 
edit a line of input from a terminal. 
The byte 


variable 
value is based on the address variable 


value$ptr 
which 
is assigned 
by calls 
to the 


primitives. 
The 
routine 
var$inp 
inputs 
and 


returns a data byte from an I/O port specified by 
a calling parameter. 
This is necessary since the 


particular 
USART to be serviced is determined by 


reading the 8259A in-service register. 


new$Ptr=b8c~~space(token); 
~f 
newiptr=length~Ptr 
then 
dummy:::ec 
ho (t oken"'l 
, • (oe 
I 1 ) , 1); 


else 
do; 
dummy=echo(token+l,.(8S,SP,BSJ,3)i 
ptr=new!ptf'; 
count=count-li 


end; 


Following this, the byte input is checked to see if 
it is a control character and if so a block within a 
DO CASE statement 
is executed. As an example 


of one of these blocks, if the character input was a 
RUBOUT the code sequence below is executed. 
The back$space 
primitive is called and a tempo- 


rary pointer is returned to a location in the queue. 
A check is made to determine 
if the line was 


empty and, if so, a bell is echoed to signal the 
operator. If the pointer returned did not indicate 


an invalid RUBOUT the real pointer is assigned 
the value of the temporary 
pointer and a back· 
space, space, backspace 
is echoed to delete the 


previous 
character 
on the screen. 
Lastly, 
the 
character 
count for the current 
line is decre- 


mented. 


VALu8~PTR=NEXT$SPACE(QuEuE$NUM8ER) 
; 
VALu8=VAR$INP(uSART~DATA$PORT(NUM) 
); 


RECEIVER 
READY 


INTERRUPT 
t 


In order 
to facilitate 
retrieval 
of the proper 


amount 
of information 
on the master 
side, the 


first byte of each message is defined to contain 
the number of characters 
in the message. 
Thus, 
when the 
master routine needs a line of input he 


uses the first byte as a count to retrieve the full 
line. The requirement 
for type-ahead 
is met by 
this mechanism 
since the number of lines in the 


queue at a given time is limited only by the length 
of the queue. When a full line of input is finished, 
the terminal 
input handler 
generates 
a slave to 


master interrupt to signal the master routine who 
may be waiting 
for this event. 


The flowchart 
for a minimal 
terminal 
output 


handler is shown in Figure 29. Upon receipt of a 


transmitter 
ready interrupt 
the output handler 
requests a character 
from the appropriate 
queue. 


If one is available it is output to the USART. If 
the queue is empty, the transmitter 
is disabled. 
Whenever the master routine sends a line into the 
queue it will generate an interrupt 
to signal the 
slave handler 
and the transmitter 
will be reen- 


abled. A line is opened via a call to open$line 
and 


it is kept open until 100 characters 
have been 
retrieved via calls to next$byte. 
At this time the 
line is closed by a call to receive making the space 
available 
to be reused. After this, a new call to 


open$line 
starts 
the process over again. 
If the 
call to get$status 
shows that the queue was full 
prior to the call to receive, an interrupt 
is sent to 


the master 
to reawaken 
any routine 
that 
may 
have 
been waiting 
for room in the queue to 
become available. 


Sample 
Master 
Software 


The RMX/80 
handler for the master single board 


computer 
that 
will communicate 
with the soft- 


ware on the iSBC 544 board is diagrammed 
in 


Figure 30. In addition, the RMX/80 
message used 


to convey information 
to the handler is shown on 


the right. The full software diagram is illustrated 
in Figure 31. 


The input driver tasks execute a reentrant 
routine 


that services a request exchange that is specified 
in an initialization 
block that is unique to each of 


the input 
tasks. 
The necessary 
information 
is 


extracted 
from the request 
message 
and 
the 


get$line 
primitive is called upon to get a line of 


input from the queue. If the call to get$line 
for the 


length byte is unsuccessful the input task waits at 


LINK 
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I 
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: 
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) 
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the appropriate 
signal exchange for an interrupt 


from the slave 
indicating 
that 
a line is now 


available. 
Once the request is fulfilled the actual 


and status fields are set and the message is sent to 
the response exchange specified by the user. 


The output handler 
performs in a manner very 


similar to the input handler. 
Upon receipt of a 


request message the handler attempts to transfer 
the 
characters 
from 
the 
user 
buffer 
to the 


appropriate queue. If the attempt is unsuccessful 
(ie. the queue has insufficient room available) the 
handler 
sends as many 
characters 
as will fit 


(count - overflow) and then waits for an interrupt 
from the slave indicating 
that 
room has been 


made available. 
This process is repeated until all 


of the data has been transmitted. 
As soon as the 


operation is complete the status field is cleared 
and the message is returned to the user specified 
response exchange. 


Since the number 
of iSBC 544 slaves 
in the 


system 
is variable 
as are the memory 
base 


address, 
device programming 
information 
and 


queue sizes, some means of providing configura- 
tion 
information 
to the RMX/80 
handlers 
is 
needed. This information 
resides 
in the mem- 


ory$allocation$module. 
Public 
variables 
are 
declared 
in this module that 
are used by the 
RMX/80 
tasks to determine how many devices 


(and therefore how many tasks need to be created) 
are in the system and where in the system address 
space their dual port RAM is located. In addition, 
queue sizes and device programming information 
are specified here. 


The intent of this application 
note has been to 
introduce 
the 
reader 
to the 
concept 
of the 
intelligent 
slave 
architecture 
and 
show 
the 
versatility 
of the first product based upon this 
architecture, the iSBC 544 Intelligent 
Communi- 
cations 
Controller. The hardware 
and software 
aspects of the device were studied and results of 
benchmark 
tests 
were presented 
and studied. 


Finally, two example applications 
were worked 
out using 
the product 
as both 
a stand-alone 
controller and as an intelligent 
slave. 


The bottom line is that the iSBC 544 controller, 
due to the advanced architecture 
around which it 


is designed, can be the means to the end for any 
application 
that 
requires 
communication. 
The 


dual 
nature 
of the controller 
provides 
the full 


power of a single board computer to the small 
application 
while the large system can make use 


of the fully programmabaJe intelligent slave to free 
the CPU for complicated processing duties. 


I would like to extend 
my gratitude 
to Dave 


Jurasek 
for the work on the throughput 
testing 


and to Jack Tyler tnman 
for aid in the design of 


the system software. 
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00E4 
00E5 
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0004 
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DB81 


0030 
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ORG 
2CH 
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XRA 
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EI 
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EXTRN 
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EXTRN 
CSEG 
01 
LXI 
OUT 
CALL 
MVI 
OUT 
MVI 
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CALL 
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80H 
0E4H 
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40FFH 
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2 


BASE 
ADDRESS 
OF 
204 


MASTER 
MODE 
SET 
ADDRESS 


MASTER 
MODE 
RESET 
ADDRESS 
READ 
COMMArW 
CODE 


TERMINAL 
COUNT 
AND 
OMA 
MODE 
~F 
DMA 
MODE 
iqORD 
TRACK 
ADDRESS 
SECTOR 
ADDRESS 


TEST 
OF 
CAPAaILITY 
FOR 
544 
TO 
SHARE 
MULTI BUS 
WITH 
OTHER 
MASTERS. 
ROUTINE 
PROGRAMS 
THE 
204 
BOARD, 
INITIATES 
A 
READ 
TRANSFER, 
WAITS 
FOR 


AN 
INTERRUPT 
AND 
THEN 
TRAPS 
TO 
ICE85 
BREAK- 


POINT 
AT 
200. 


Mt'lSET 
BASE+! 
A 
ERRTRP 


INl'T24 
WAITC 
WAITP 


SP,0BFFFH 
MMSET 
INIT24 
A,DMAMOO 
BASE+8 
A,LOW(TCOUNT) 
BASE+5 
A,HIGH(TCOUNT) 
BASE+5 
A,LOW(BUFFER) 
BASE+4 
A,HIGH(BUFFER) 
BASE+4 
WAI'rC 
A,READ 
BASE+0 
WAITP 
A,TADDR 
BASE+l 
WAITP 
A,SADDR 
SASE+l 
Mt'lRSET 


;RST 
5.5 
ENTRY 
POINT 


;SET 
MASTER 
MODE 


;GET 
RESULT 
;SET 
FLAGS 
;NON-ZERO 
RESULT; 
ERROR 
TRAP 


;REENABLE 
;CONTINUE 
ON 


;204 
INITIALIZATION 
ROUTINE 


;WAIT 
FOR 
204 
NOT 
BUSY 
ROUTINE 


;WAIT 
FOR 
204 
PARAMETER 
REGISTI 


;DISABLE 
;SET 
STACK 
POINTER 


;SET 
MASTER 
MODE 
FLIP 
FLOP 


;INITIALIZE 
204 


;SET 
DMA 
MODE 


58 
EI 


59 
HLT 


60 
JMP 
200H 


61 ERRTRP: 
62 
HLT 


63 
END 


ENABLE 
AND 
HALT 
; WAIT 
FOR 
INTEF 
TRAP 
TO 
ICE85 
BREAKPOINT 
AT 
200 
ERROR 
TRAP 
FOR NOW 


0034 
FB 
0035 
76 
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C30002 


PUBLIC 
SYMBOLS 


EXTERNAL 
SYMBOLS 
INIT24 
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WAITC 
E 0000 
WAITP 
E 0000 


USER 
SYMBOLS 
BASE 
A 0080 
BUFFER 
0 0000 
DMAMOD 
A 0004 
ERRTRP 
C 0039 
INIT24 
E 0000 
JotF 
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A 0052 
SADDR 
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1 
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2 
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NOT 
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SPECIFY 
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HEAD 
SETTLE 
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PARAMETER 
REGISTER 
FULL 
AE 
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~035 
3E35 
55 
MVI 
A ,SPECF~ 
:SPECIF~ 
BAD 
TRACKS 


~0 37 
D3ill? 
56 
OUT 
BASE+~ 


0039 
CDI\U0 
C 
57 
CALL 
WAITP 
, 


~1I3C 3El11 
58 
MVI 
A,BADTRI 
:BAD 
'rRACKS 
FOR 
SURFACE 
1 


003E 
D381 
59 
ou'r 
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0040 
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C 
S~ 
CALL 
WAITP 
, 


1111433EFF 
61 
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A,NoaAo 
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WAITP 
, 


004A 
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, 
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DOES 
IT 
0088 
FB 
91 
EI 
:ENABLE 
INTERRUPTS 


11089 76 
92 
HL'r 
:SLEEP 


01l8A F3 
93 
01 
;DISABLE 


008B 
3E04 
94 
MVI 
A,DMAMOD 
:S ET 
OMA 
MODE 


0080 
0388 
95 
OUT 
BASE+8 
, 


008F 
3E00 
96 
MVI 
A,LOW(TCOUNT) 
;SET 
CON'rROL 
REGIS'rER 


0091 
0385 
97 
OUT 
3ASE+5 


0093 
3E40 
98 
MVI 
A, HIGH ('rCOUNT) 


0095 
0385 
99 
OUT 
BASE+5 


0097 
FB 
100 
EI 
, 


009il C9 
101 
RET 
:RETURN 
102 
103 
WAITC 
AND 
WAITP 
ROUTINES 
1~4 
, 


0099 
0380 
105 
WAITC: 
IN 
BASE+>:! 
GE'r STATUS 
BYTE 


0098 
E680 
11')6 
ANI 
BUSY 
BUSY? 


01190 C29900 
C 
H7 
JNZ 
WAITC 
YES ,LOOP 


00A0 
C9 
108 
RET 
NO,RETURN 
109 
, 


00Al 
OB8~ 
110 
WAITP: 
IN 
BASE+kl 
GET 
STATUS 
REGISTER 
00A3 
E620 
111 
ANI 
PARFUL 
PARAMETER 
BUFFER 
FULL? 
00A5 
C2AU0 
C 
112 
JNZ 
WAITP 
YES,LOOP 


01lA8 C9 
113 
RET 
NO, RETURN 
114 
END 


PUBLIC 
SYM80LS 


INIT24 
C 
0000 
WAITC 
C 
1?099 
WAITP 
C 
011Al 


USER SYMdOLS 
BADTRl 
A IlIH0 
INIT24 
C 0000 
SEEK 
A 0069 


BADTR2 
A 0018 
LOAD 
A 0009 
SETTLE 
A 0008 


BASE 
A 0080 
MMRSET 
A 00E5 
SPECFY 
A 0035 


BUSY 
MMSET 
STEP 


A 0080 
A 00E4 
A 0008 


CHARS 
II 000D 
NOBAD 
A 00FF 
TCOUNT 
A 
4000 
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ISIS-II 
PL/M-W0 
V3.l COMPILATION 
OF MODULE 
MAINLINE 
OBJECT 
MODULE 
PLACED 
IN :Fl:MAINLN.OBJ 


COMPILER 
INvOKED 
BY: 
PLM80 
:Fl:MAI~LN.PLM 
PRINT(:F5:MAINLN.LST) 
PAGEWIOTH(78) 


$title('slave 
mainline 
routine') 
main$line: 
DO; 


Mainline 
routine. 
Sets 
UD 
stack$ptr, 
calls 
s$init 
to 
init- 
ialize queues,initializes 
some of the hardware, 
sets up the 


initial 
flag 
interrupt 
handlers, 
and then halts with 
interru 


pts 
enabled 
allowing 
the rest of the system 
to operate 
totally 


in i~terrupt 
mode. 


initial$handler: 
PROCEDURE 
EXTERNAL; 
END initial$handler; 


DECLARE 
command$word 
LITERALLY 
'41h', 
port$a$8155 
LITERALLY 
'0e9h', 
command$8155 
LITERALLY 
'0e8h', 
mask$8259 
LITERALLY 
'0e7h', 
icwl$8259 
LITERALLY 
'0e6h', 
icw2$8259 
LITERALLY 
'~e7h', 
ocw3$8259 
LITERALLY 
'0e6h', 
read$isr 
LI'rERALLY 
'''bh', 
mask$word 
BYTE PUBLIC, 
port$a$value 
BYTE PU8LIC, 
stat 
BYTE, 
i BYTE; 


output(icwl$8259)=0f6h; 
output(icw2$8259)=0fh; 
output(mask$8259) ,mask$word=0ffh; 


output (command$8155) =command$word; 
output(port$a$8155) ,port$a$value="c0h; 
DO i=0 TO 
7; 
stat=set$handler(i,.initial$handler); 


25 
2 
END; 


26 
1 
DO 
WHILE 
1; 


27 
2 
HALT; 


28 
2 
END; 


29 
1 
END 
main$line; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


72 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


004DH 
1l004H 
'" ~1l02H 


77D 
4D 
2D 


ISIS-II 
PL/M-80 
V3.1 COMPILATION 
OF MODULE 
INITIALHANDLER 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:FINTRT.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:FINTRT.PLM 
PRINT(:F5:FINTRT.LST) 
PAGEWIDTH(78) 


$title('slave 
application 
level 
signal 
handler') 
initial$handler: 
DO; 


Fields 
application 
level 
flag 
interrupts 
from 
the 
master. 
If the type=go$type 
the device 
attached 
to the queue 
specified 
is initialized 
with 
programming 
info sent 
into 
the queue 
by the master. 
If the type 
is data$available 
the 
specified 
transmitter 
is enabled 
unless 
a control$s 
pause 
is in effect. 


DECLARE 
no$pause 
LITERALLY 
'1', 
go$type 
LITERALLY 
'1', 
data$available 
LITERALLY 
'2', 
enable$xmit 
LITERALLY 
'1', 
reset 
LITERALLY 
'40h', 
timer$l$command$port 
LITERALLY 
'0dbh', 
timer$2$command$port 
LI'rERALLY 
'kldfh', 
mask$8259 
LITE~ALLY 
'0e7h', 


mask$word 
BYTE EXTERNAL, 
mask 
(8) BYTE DATA( 


0fch, 
0fch, 
klf3h, 
0f3h, 
0cfh, 
0cfh, 
03fh, 
03fh) , 
transmitter$state 
(8) BYTE 
PUBLIC, 
type 
BYTE, 
token 
BYTE, 
i 
BYTE, 
prog$info 
(5) BYTE, 
actual ADDRESS, 
~sart$command$port 
(8) BYTE EXTERNAL, 
usart$state 
(8) BYTE PUBLIC,' 


length$pointer 
(8) ADDRESS 
PUBLIC, 
pointer 
(8) ADDRESS 
PUBLIC, 
char$count 
(8) BYTE PUBLIC, 
timer$load$oort 
(8) BYTE DATA( 
0d8h, 


33 
1 


34 
2 


35 
2 
36 
2 


37 
2 
38 
2 
39 
3 


40 
3 
41 
4 
42 
4 


43 
3 


44 
3 


45 
3 
46 
3 


47 
3 
48 
3 


49 
3 
50 
3 
51 
3 


52 
3 
53 
3 
54 
3 
55 
3 
56 
3 


57 
2 


58 
2 
59 
3 
60 
3 


61 
3 


0d8h, 
0d9h, 
0d9h, 
0dah, 
0dah, 
0dch, 
0dch} : 


token=code 
AND 
0fh; 
type=shr(code,4) 
; 


If 
type=go$type 
THEN 


DO; 
transmitter$state(token)=no$pause: 


/* 
reset 
usart 
*/ 


DO 
i=0 
TO 
3: 
CALL 
varout(usart$command$port(token) 
,0): 


El'W: 


CALL 
varout(usart$command$port(token) 
,prog$info(0»): 


CALL 
varout(usart$command$port(token) 
,usart$state(token) 


:=prog$info(1}} 
: 
IF 
token 
< 
7 THEN 
CALL 
varout 
(timer$1$command$port 
,prog$info 
(2) 
: 
ELSE 
CALL 
varout(timer$2$command$port,prog$info(2}}; 
CALL 
varout 
(timer$1oad$port 
(token) 
,prog$info 
(3): 
CALL 
varout(timer$1oad$port(token) 
,prog$info(4}}: 


1ength$pointer(token-1}=new$1ine(token-1} 
: 
pointer(token-l)=next$space(token-1): 
char$count(token-1)=0: 
output(mask$8259} 
,mask$word=mask$word 
AND 
mask(token): 
END: 


ELSE 
IF 
(type=data$avai1ab1e) 
AND 
(transmitter$state(token}=no$pa 
use) 
THEN 


DO: 
usart$state(token)=usart$state(token) 
OR 
enab1e$xmit: 


CALL 
varout(usart$command$port(token) 
,usart$state(token) 


RET(JRN; 
END; 


CODE AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
154 LINES 
READ 
o PROGRAM 
ERROR(S) 


0182H 
0kl43H 
0004H 


3860 
670 
40 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
INPUTHANDLER 
OBJECT 
MODULE 
PLACED 
IN :FI:INHDLR.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:FI:INHDLR.PLM 
PRINT(:F5:INHDLR.LST) 
PAGEWIDTH(78) 


$nointvector 
title('slave 
terminal 
input handler') 
input$handler: 
DO; 


544 resident 
interrupt 
service 
routine. 
After 
receiver 


ready 
interrupt 
the 8259' In Service 
Register(ISR) 
is 


read to determine 
which 
device 
is requesting 
service. 


The character 
is read 
in and placed 
in the ap?ropriate 


queue. 
A check 
is made 
for break 
characters 
and appropriate 


action 
is taken 
if any are found. 
When 
an endline 
character 


is encountered 
the length 
byte 
is filled 
in 
( it was 
left 


vacant 
when 
the line was 
started) 
and the xmit primitive 
is 


called 
to update 
the global 
queue 
pointer 
to permit 
access 


to the line. At this time the master 
is signalled 
to signify 


that a new 
line is available 
for processing. 


DECLARE 
control$x 
LITERALLY 
'18H' , 
control$s 
LITERALLY 
'13H', 
control$a 
LITERALLY 
'1lH' , 
rubout 
. 
LITERALLY 
'7FH', 
escape 
LITERALLY 
'ISH', 
CR 
LITERALLY 
'00H', 
LF 
LITERALLY 
'0AH', 
as 
LITERALLY 
'~8H', 
SP 
LITERALLY 
'20H', 
bell 
LI'rERALLY' 
07H' , 
~tr 
LITERALLY 
'pointer (token) '. 
length$ptr 
LITERALLY 
'length$pointer(token)', 


count 
LITERALLY 
'char$count(token) , 
disable$xmit 
LITERALLY 
'~FEH', 
enable$xmit 
LI'rERALLY 
'0lH' , 
no$pause 
LIT~RALLY 
'1', 
pause 
LITERALLY 
'0', 
line$available 
LITERALLY 
'1', 
ocw2$8259' 
LITERALLY 
'I1E6H', 
ocw3$tl259 
LI'rERALLY 
'0E6H' , 
EOr 
LITERALLY' 
20H '; 


DECLARE 
value$ptr 
ADDRESS, 
value 
BASED value$ptr 
BYTE, 
line$length 
BASED value$ptr 
BYTE, 


dummy 
ADDRESS, 
rSR BYTE, 
token 
BYTE, 


37 
1 
38 
2 


39 
2 
41 
2 
43 
2 
45 
2 
47 
2 
49 
2 
51 
2 
52 
2 


53 
1 


54 
2 


55 
2 
56 
2 
57 
2 
58 
2 
59 
2 


60 
1 


61 
2 
62 
2 
63 
2 
64 
2 
65 
2 
66 
2 


67 
1 


68 
2 
69 
2 
70 
2 
71 
2 
72 
2 
73 
2 
74 
2 
75 
2 
76 
2 
77 
2 


stat 
BYTE, 
new$ptr 
ADDRESS; 


DECLARE 
pointer 
(8) ADDRESS 
EXTERNAL, 
length$pointer 
(8) ADDRESS 
EXTER~AL, 
char$count 
(8) BYTE 
EXTER~AL, 
usart$state 
(8) BYTE EXTERNAL, 
usart$command$port 
(8) BYTE EXTERNAL, 
usart$data$port 
(8) BYTE EXTERNAL, 
transmitter$state 
(8) BYTE EXTERNAL; 


index: 
PROCEDURE 
(value) BYTE; 
DECLARE 
value 
BYTE; 


IF value=control$x 
THEN 
RETURN 
0; 
IF value=rubout 
THEN 
RETURN 
1; 
IF value=control$s 
THEN 
RETURN 
2; 
IF value=control$q 
THEN 
RETURN 
3; 
IF value=escape 
THEN 
RETURN 
4; 
IF value=CR 
THEN 
RETURN 
5; 
RETURN 
6; 
END; 


DEC~~RE 
(buf$ptr,num$char,actual) 
ADDRESS, 
token BYTE; 


actual=send$line(token,buf$ptr,num$char) 
; 
usart$state(token)=usart$state(token) 
OR enable$xmit; 


CALL varout(usart$command$port(token) 
,usart$state(token»; 


RETURN 
actual; 
END; 


length$ptr=new$line(token); 
ptr=next$space(token) 
; 
count=0; 
dummy=echo(token+l,. 
('t',CR,LF) ,3); 
RETURN; 
END; 


value$ptr=length$ptr; 
line$length=count; 
ptr=next$space(token); 
stat=xmit(token); 
length$ptr=new$line(token); 
ptr=next$space(token) 
; 
count="; 
stat~set$s$interrupt(token,line$available); 
RETURN; 
END; 


78 
1 
79 
2 


80 
2 


81 
2 


82 
2 
83 
2 
84 
3 


86 
3 


87 
4 
88 
4 
89 
4 


90 
3 
91 
2 
92 
2 


93 
2 


94 
3 
95 
4 
96 
4 


97 
3 
98 
4 
99 
4 
100 
4 


101 
4 
102 
5 
103 
5 


104 
5 
105 
5 
106 
4 


107 
3 
108 
4 


109 
4 


IHl 
4 
III 
4 


112 
3 
113 
4 


in$hdlr: 
PROCEDURE 
INTERRUPT 
0 PUBLIC; 
ISR:input(ocw3$8259) 
; 


again: 


ISR:sh 1 (ISR,2); 


IF NOT carry THEN 
DO; 
IF token:~ 
THEN 
RETURN; 
/* no bits set */ 


ELSE 
DO; 
token:token-2; 
GOTO 
again; 
END; 


END; 


value$ptr:ptr; 
value:varinp(usart$data$port(token)) 
AND 
~7fh; 


CALL delete$line; 
END; 


new$ptr:back$space(token) 
; 
IF new$ptr:length$ptr 
THEN 
dummy:echo(token+l,. 
(bell) ,1); 
ELSE 
DO; 


dummy:echo(token+l,. 
(BS,SP,aS) ,3); 
ptr:new$ptr; 
count:count-l; 
END; 


transmitter$state(token+l):pause; 
END; 


/* case 3; control$g; 
resume 
output 
*/ 
DO; 


114 
4 


115 
4 
116 
4 


117 
3 
118 
4 
119 
4 


12(1 
4 


121 
4 


122 
4 


123 
3 
124 
4 


125 
4 


126 
4 


127 
4 


128 
4 


129 
4 
130 
4 
131 
4 


132 
3 


133 
4 
134 
4 
135 
4 
137 
4 
138 
4 


139 
3 
140 
2 


141 
2 


142 
2 


143 
1 


transmitter$state(token+l);no$pause; 
El~D; 


/* case 4; escape; 
terminate 
line 
*/ 


DO; 
dummy;echo(token+l,. 
('#' 
,CR,LF) ,3); 
value;CR; 
count;count+l ; 
CALL end$line; 


El~D; 


/* case 5; carriage 
return; 
terminate 
line 
*/ 


DO; 
dummy;echo(token+l,. 
(CR,LF) ,2); 


count;count+l; 
ptr;next$space(token) 
; 
value$ptr;ptr.; 
value;LF; 
count;count+l; 
CALL 
end$line; 


END; 


/* case 6; non-break 
character; 
stuff 
into queue 
*/ 


DO;' 


dummy;echo(token+l,ptr,l); 
ptr;next$space(token) 
; 
IF ptr;0 
THEN 
CALL delete$line; 
/* full buffer 
*/ 


ELSE count;count+l; 


END; 


END; /* of do case 
*/ 
output(ocw3$8259);EOI; 


CODE AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


255 LINES 
READ 


o PROGRAM 
ERROR(S) 


0398H 
0011H 
il0113H 


9200 
17D 
160 


ISIS-II 
PL/M-8~ 
v3.l COMPILATION 
OF MODULE 
OUTPUTHA~DLER 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:OUTHLR.08J 


COMPILER 
INVOKED 
BY: 
PLM8~ 
:Fl:OUTHLR.PLM 
PRINT(:F5:0UTHLR.LST) 
PAGEWIDTH(78) 


$nointvectoc 
title('slave 
chacactec 
output 
handlec') 
output$handlec: 
DO; 


544 cesident 
inteccupt 
secvice 
coutine. 
Aftec 
tcansmittec 


ceady 
inteccupt, 
8259 In Secvice 
Registec(ISR) 
is cead to 
detecmine 
which 
device 
is cequesting 
secvice. 
A chacactec 


is cequested 
fcom the apPcopciate 
queue 
and, 
if available, 


is sent to the usact. 
If the queue 
is empty 
the tcansmittec 
is disabled 
pending 
a signal 
fcom the mastec 
when moce 


chacactecs 
ace put 
into the queue. 


DECLARE 
ocw2$8259 
LITERALLY 
'0E6H', 
ocw3$8259 
LI'rERALLY 
'0E6H' , 
disable$xmit 
LITERALLY 
'0FEH', 
tcue 
LITERALLY' 
iIlFFH' 
, 
false 
LITERALLY 
'00H', 
EOI 
LITERALLY 
'0A0H'; 


DECLARE 
ISR BYTE, 
token 
BYTE, 
actual 
ADDRESS, 
value 
13YTE; 


DECLARE 
usact$state 
(8) BYTE EXTERNAL, 
usact$command$poct 
(8) BYTE 
PUBLIC 
DATA ( 
0D1H, 
0D1H, 
0D3H, 
003H, 
0D5H, 
0D5H, 
~07H, 
0D7H) , 
usact$data$poct 
(8) BYTE PUBLIC 
DATA ( 


0D0H, 
0D0H, 
0D2H, 
0D2H, 
0D4H, 


15 
2 


16 
2 


17 
2 


18 
2 
19 
2 
20 
3 


22 
3 
23 
4 
24 
4 
25 
4 
26 
4 
27 
3 


28 
2 
29 
2 
30 
2 
31 
3 


32 
3 


33 
3 


34 
2 
35 
2 
36 
2 
37 
2 
38 
1 


0D4H, 
0D6H, 
~D6H) ; 


PROCEDURE 
INTERRUPT 
1 PUBLIC; 


/* get active 
level number 
and use 
it to determine 
queue$token 
* 
/ 


again: 
ISR=shl (ISR,l); 
IF NOT carry THEN 
DO: 
IF token=l 
THEN 
RETUR~: 
/* no bits 
in ISR set 
*/ 
ELSE 
DO: 
token=token-2: 


, ISR=shl(ISR,l): 
GOTO 
again: 
END: 


actual=get$line(token,.value,l): 
IF actual=\1 THEN 
DO: /* empty queue. 
Disable 
transmitter 
*/ 
usart$state(token)=usart$state(token) 
AND disabl 


END: 
ELSE 
CALL varout(usart$data$port(token) 
,value): 
output(ocw3$8259)=EOI: 
RETURN: 
3ND: 
END output$handler: 


CODE AREA 
SIZE 
VARIABLE 
AREA SIZE 
MAXIMUM 
STACK 
SIZE 
102 LINES 
READ 
\1PROGRAM 
ERROR(S) 


\10A4H 
0iil05H 
000CH 


1640 
50 
120 


ISIS-II 
PL/M-80 
V3.1 COMPILATION 
OF MODULE 
INIT544 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:INIT54.0BJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:INIT54.PLM 
PRINT(:F5:INIT54.LST) 
PAGEWIDTH(78) 


$title('rmx/8~-544 
initialization 
task') 
init$544: 


DO; 


Task 
code 
for 544 driver 
initialization 
task. 
Info 
from aoplication 
supplied 
memory 
allocation 
block 
is accessed 
to set up queues 
and 
transfer 
device 
programming 
info to the slave 
board(s) 
and create 
the required 


service 
handler 
tasks. 


input$driver: 
PROCEDURE 
EXTERNAL; 
END input$driver; 


output$driver: 
PROCEDURE 
EXTERNAL; 
END output$driver; 


signal: 
PROCEDURE 
EXTERNAL; 
END signal; 


DECLARE 
stack$size 
LITERALLY 


go$type 
LITERALLY 
'256 I, 
'11 
: 


DECLARE 


ptr 
ADDRESS, 
init$table 
BASED ptr STRUCTURE ( 
base$adr 
ADDRESS, 
gueue$token 
BYTE, 


prog$info 
(5) BYTE), 
i 
BYTE, 
overflow 
ADDRESS, 
queue$init$table 
(1) STRUCTURE ( 
base$adr 
ADDRESS, 
aueue$size 
(8) ADDRESS) 
EXTERNAL, 
initialization$table 
(1) BYTE 
EXTERNAL, 
stat 
BYTE, 


num$devices 
BYTE 
EXTERNAL, 
num$boards 
BYTE 
EXTERNAL, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 
signal$exchange$table 
(1) ADDRESS 
EXTERNAL, 
service$exchanges 
(1) BYTE 
EXTERNAL. 


signal$exchanges 
(1) BYTE EXTERNAL, 
task$descriptors 
(1) BiTE EXTERNAL. 


65 
1 


66 
2 


67 
2 
68 
2 
69 
2 
70 
2 
71 
2 


72 
1 


73 
2 
74 
3 
75 
3 


76 
2 


77 
2 


78 
2 


79 
2 


80 
3 


81 
3 


stacks 
(1) BYTE EXTERNAL, 
info$block 
(1) STRUCTURE ( 
base$adr 
ADDRESS, 
queue$token 
BYTE, 
index BYTE) EXTERNAL, 
rqactv 
ADDRESS 
EXTERNAL; 


DECLARE 
:om$input$std 
static$task$descriptor 
DATA( 
'input' 
, 
.input$driver, 
0, /* stack will be assigned 
individually 
*/ 
stack$size, 
200, 
0, /* tba */ 
0), /* tba */ 
rom$output$std 
static$task$descriptor 
DATA( 
'output' , 
.output$driver, 
0, 
stacksize, 
201, 
0, 
0) , 
input$hdlr$std 
static$task$descriptor, 
output$hdlr$std 
static$task$descriptor; 


init$xch: 
PROCEDURE 
(xch$ptr); 
/* 
initializes 
expanded 
interrupt 
exchanges 
*/ 


DECLARE 
xch$ptr 
ADDRESS, 
xch BASED 
xch$ptr 
int$exchange$descriptor; 


xch.link=.xch.link; 
xch.type=int$type; 
xch .length=5; 
RETURN; 
END: 


DO 
i=0 TO num$boards-l; 
CALL m$init(.queue$init$table(i»; 
END; 


CALL move (size(rom$output$std) ,.rom$output$std,.output$hdlr$ 
std) ; 
ptr=.initialization$table; 


DO i=0 TO num$devices*2 
BY 2; 
/* send pogramming 
info to slave 
*/ 
overflow=send$line(init$table.base$adr,init$table.queue$ 
token,.init$table.prog$info,5); 
stat=set$m$interrupt(init$table.base$adr,init$table.queu 


82 
3 


83 
3 


84 
3 
85 
3 
86 
3 


87 
3 


8~ 
3 


89 
3 
911 
3 
91 
3 
92 
3 


93 
3 
94 
3 
95 
3 
96 
3 
97 
3 
9B 
3 


99 
3 
llilfrl3 
Hll 
3 
Hl2 
3 


lIB 
2 
Ifrl4 
2 
HIS 
2 
186 
2 


187 
1 


CALL 
rqcxch(service$exchange$table(i) 
:=.service$exchange 
s+HI*i) ; 
CALL 
rqcxch(service$exchange$table(i+l):=.service$exchan 


ges+HI*(i+l» 
; 
CALL 
init$xch(.signal$exchanges+15*i); 
CALL 
init$xch(.signal$exchanges+15*(i+l»; 


CALL 
rqcxch(signal$exchange$table(i):=.signal$exchanges+ 


CALL 
rqcxch(signal$exChanqe$table(i+l):=.signal$exchange 


s+15* (i+1»; 


info$block(i).base$adr, 
info$block(i+l).base$adr=init$table.base$adr; 
info$block(i) 
.queue$token=init$table.queue$token-l; 


info$bloCk(i+l).queue$token=init$table.queue$token; 
info$block(i) 
.index=i; 
info$block(i+l).index=i+l; 


input$hdlr$std.sp=.stacks+stack$size*i; 
output$hdlr$std.sp=.stacks+stack$size*(i+l); 
input$hdlr$std.exchange$address=.info$block(i); 
output$hdlr$std.exchange$address=.info$block(i+l); 
input$hdlr$std.task$ptr=.task$descriptors+20*i; 
output$hdlr$std.task$ptr=.taskSdescriptors+21l*(i+l); 


CALL 
rqctsk(.inputShdlr$std); 
CALL 
rqctsk(.output$hdlr$std); 
ptr=ptr+8 
; 


END; 


CALL 
rqsetv(.signal,2); 


CALL 
rqelvl(2); 


CALL 
rqsusp(rqactv); 
END; 
/* 
of 
task 
*/ 


END 
initS544; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


285 
LINES 
READ 


frlPROGRAM 
ERROR(S) 


'"02C3H 
•• 01l2AH 
il086H 


7frl7D 
42D 
6D 


ISIS-II 
PL/M-8~ 
V3.1 COMPILATION 
OF MODULE 
INITMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:MAB.OBJ 


COMPILER 
INVOKED 
BY: 
PLMB0 
:Fl:MAB.PLM 
PRmT(:F5:ll\AB.LST) PAGE~I0TH(78) 


$title('rmx/8~-544 
initialization 
module 
and memory 
allocation 
b 
lock' ) 
init$module: 
DO; 


OECLARE 
number$of$devices 
LITERALLY 
'4', 


baud$rate$count:?l 
LITERALLY 
'32', 


baud$rate$count$h 
LITERALLY 
I ~~' 
, 


usart$mode 
LITERALLY' 
4eh ', 


usart$cmd 
LI'rERALLY' 
27h', 


ctr$0$mode 
LITERALLY 
'36h', 


ctr$l$mode 
LITERALLY' 
76h' , 


ctr$2$mode 
LI'rERALLY' 
0b6h' , 


ctr$3$mode 
LITERALLY 
'36h', 


num$devices 
BYTE PUBLIC 
DATA(number$of$devices-l), 
num$boards 
BYTE PUBLIC 
DATA(l), 


serv ice$exchange$ table 
(8)'ADDRESS 
PUBLIC, 


signal$exchange$table 
(8) ADDRESS 
PUBLIC, 


signal$type 
(8) BYTE PUSLIC, 


service$exchanges 
(80) BYTE PUBLIC, 


signal$exchanges 
(120) BYTE PuBLIC, 


task$descriptors 
(160) BYTE 
PUBLIC, 


stacks 
(2048) BYTE PUBLIC, 


info$block 
(32) BYTE PUBLIC, 


gueue$init$table 
(1) STRUCTURE ( 
base$adr 
ADDRESS, 
gueue$size 
(8) ADDRESS) 
PUBLIC 
DATA( 
0e0 il0h, 
256, 
1765, 
256, 
1765, 
256, 
176'5, 
256, 
1765) , 


base$table 
(1) ADDRESS_PUBLIC, DATA ( 
0e000h) , 


initialization$table 
(number$of$devices) 
STRUCTURE ( 


base$adr 
ADDRESS, 


queue$token 
BYTE, 
prog$info 
IS) 
BYTE) 
PUBLIC 
DATAl 
l'Je000h, 
1, 
usart$mode, 
usart$cmd, 
ctr$l'J$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


l'Je00l'Jh, 
3, 
usart$mode, 
usart$cmd, 
ctr$l$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


0e0idl'Jh, 
5, 
usart$mode, 
usart$cmd, 
ctr$2$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


l'Jel'J 
I'Jl'Jh, 
7, 
usart$mode, 
usart$cmd, 
ctr$3$mode, 
baud$rate$count$l, 
baud$rate$count$h) 
; 
END 
init$module; 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
79 
LINES 
READ 
" 
PROGRAM 
ERROR 
IS) 


1'J1'J36H 
09BI'JH 
I'JI'JI'JI'JH 


54D 
24800 
I'JD 


ISIS-II 
PL/M-8~ 
V3.1 
COMPILATION 
OF 
MODULE 
SIG~ALHANDLER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:SIGNAL.OBJ 


COMPILER 
INVOKED 
BY': 
PLM8fl: 
Fl :SIGNAL.PLM 
PRINT 
(:F5 :SIGNAL. 
LS'r) PAGEWIDTH 
(78) 


$nointvector 
title('slave->master 
interrupt 
handler') 
signal$handler: 
DO; 


DECLARE 
i 
BY'TE, 
ptr 
ADDRESS, 
(flag 
BASED 
ptr) 
BYTE, 
num$boards 
BY'TE EXTERNAL, 
num$devices 
BYTE 
EXTERNAL, 
signal$type 
(1) 
BY'TE EXTERNAL, 
index 
BYTE, 
token 
BYTE, 
signal$exchange$table 
(1) 
ADDRESS 
EXTERNAL, 
base$table 
(1) 
ADDRESS 
EXTERNAL; 


signal: 
PROCEDURE 
INTERRUPT 
2 
PUBLIC; 


next: 
ptr=base$table(i)+l; 
IF 
Elag=0 
THEN 
DO; 
i=i+l; 
IF 
i 
> 
num$boards 
THEN 
RETURN; 
/* 
erroneous 
signal 
* 


ELSE 
GOTO 
next; 
END; 


/* 
get 
queue 
token 
and 
use 
it 
to 
index 
into 
signal 
exchange 
tabl 
e 
*/ 


token=(flag 
AND 
~fh); 
index=4*i+token; 


39 
2 
IF index <= num$devices 
THEN 


40 
2 
DO; 


41 
3 
CALL 
rqisnd(signal$exchange$tab1e(index» 
; 
42 
3 
signal$type(index)=shr(flag,4); 


43 
3 
END; 


ELSE 


44 
2 
CALL 
rqendi; 


/* zero fiag to acknowledge 
interrupt 
*/ 


45 
2 
flag=0 ; 


46 
2 
RETURN; 


47 
2 
END; 


48 
1 
END signa1$hand1er; 


CODE AREA SIZE 
VARIABLE 
AREA SIZE 


MAXIMUM 
STACK 
SIZE 


110 LINES 
READ 
o PROGRAM 
ERROR(S) 


008BH 
0005H 
000AH 


1390 
5D 
100 


ISIS-II 
PL/M-80 
V3.1 COMPILATION 
OF MODULE 
INPUTDRIVER 
OBJECT 
MOCULE 
PLACED 
IN 
:Fl:INPUT.OBJ 


COMPILER 
INVOKED 
BY: 
PLM8~ 
:Fl:INPUT.PLM 
PRINT(:F5:INPUT.LST) 
PAGEWIDTH(78) 


$title('rmx/80-544 
input service 
handler') 
input$d river: 
DO: 


Master 
resident 
task code. Monitors 
service 
exchange 


and fills 
input requests 
by retrieving 
characters 
from 
the proper 
gueue(board$base 
and device 
info is passed 
via default 
exchange 
field). 
By definition 
the first 
byte 
of a line of 
input contains 
the length 
of that line. 
This 
figure 
is used 
to retrieve 
the exact 
number 
of characte 


DECLARE 
rqactv 
ADDRESS 
EXTERNAL, 
td gASED 
rqactv 
task$descriptor, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 


signal$exchange$table 
(1) ADDRESS 
EXTERNAL: 


DECLARE 
service$exchange 
ADDRESS, 
board$base 
ADDRESS, 


queue$token 
BYTE, 
signal$exchange 
ADDRESS, 
msg$ptr 
ADDRESS, 
msg BASED msg$ptr 
th$msq, 
actual 
ADDRESS, 
dummy 
ADDRESS, 
info$block$ptr 
ADDRESS, 
info$block 
BASED 
info$block$ptr 
STRUCTURE ( 


base$adr 
ADDRESS, 
queue$token 
BYTE, 
index 
BYTE) , 
num$char 
BYTE, 
stat 
BYTE: 


/* get 
info out of default 
field 
*/ 


info$block$ptr=td.exchange$address: 
/* default 
exchange 
fiel 


d 
*/ 
service$exchange=service$exchange$table(info$block.index): 


board$base=info$block.base$adr; 
queue$token=info~block.queue$token; 
signal$exchange=signal$exchange$table(info$block.index); 
DO 
forever; 


retry: 
/* 
try 
to 
get 
line 
count 
out 
of 
queue 
*/ 


actual=get$line(board$base,queue$token,.num$char,l) 
; 


/* 
if 
unsuccessful 
wait 
for 
signal 
and 
try 
again 
*/ 


IF 
actual=1:l THEN 
DO; 
dummy=rqwait(signal$exchange,0); 
GOTO 
retry; 
Et'lO; 


actual=get$line(board$base,queue$token,msg.buffer$adr,nu 


m$char) 
; 
~sg.actual=actual; 
msg.status=0; 
CALL 
rqsend(msg.resp$ex,msg$ptr); 


END; 
/* of 
do 
forever 
*/ 


0l2CH 
00008 
00178 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


171 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


3000 
00 
230 


ISIS-II 
PL/M-8~ 
V3.1 COMPILATION 
OF MODULE 
OUTPUTDRIVER 
OBJECT 
MODULE 
PLACED 
IN :Fl:OUTPUT.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:OUTPUT.PLM 
PRINT(:F5:0UTPUT.LST) 
PAGEWIDTH(78) 


$title('rmx/8~-544 
output 
service 
handler') 
output$driver: 
00; 


Master 
resident 
task code. Monitors 
service 
exchange 
and 


fills output 
requests 
by stuffing 
characters 
into the approp 


riate 


queue. 
If insufficient 
room 
is available 
the task waits 


for 1 second 
and retries 
up to 100 times 
after which 
it 


signals 
a time out error. 
If the transmission 
completes 


successfully 
the slave 
is signalled 
to indicate 
that data 
is 


DECLARE 
data$available 
LITERALLY 
'2', 
time$out 
LITERALLY 
'1'; 


DECLARE 
rqactv 
ADDRESS 
EXTERNAL, 
(td BASED 
rqactv) 
task$descriptor, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 
signal$exchange$table 
(1) ADDRESS 
EXTERNAL; 


DECLARE 
service$exchange 
ADDRESS, 
signal$exchange 
ADDRESS, 
base$adr 
ADDRESS, 


queue$token 
BYTE, 
msg$ptr 
ADDRESS, 
msg BASED msg$ptr 
th$msg, 
tries$left 
BYTE, 


overflow 
ADDRESS, 
dummy 
ADDRESS, 
stat 
BYTE, 


info$block$ptr 
ADDRESS, 


info$block 
BASED 
info$block$ptr 
STRUCTURE ( 


base$adr 
ADDRESS, 
queue$token 
BYTE, 
index 
BYTE) ; 


43 
2 
44 
2 
45 
2 
46 
2 
47 
2 


48 
2 


49 
3 


50 
3 
51 
3 


52 
3 
53 
3 
54 
4 
55 
4 


56 
4 


58 
4 
59 
5 
60 
5 
61 
5 
62 
5 


63 
4 
64 
3 
65 
3 


66 
3 
67 
3 


68 
3 


69 
2 


70 
1 


info$block$pt~=td.exchange$add~ess; 
se~vice$exchange=se~vice$exchange$table(info$block.index); 
signal$exchange=signal$exchange$table(info$block.index) 
; 
bas=$ad~=info$block.base$ad~; 
queue$token=info$block.gueue$token; 


msg$pt~=~qwait(se~vice$exchange,0) 
; 
t~ies$left=100; 


ove~flow=send$line(base$ad~,queue$token,msg.buffe~$ad~,m 
sg.count) ; 
IF ove~flow 
<> 
0 THEN 
DO; 
dummy=~qwait(signal$exchange,20) 
; 
t~ies$left=t~ies$left-l; 
IF t~ies$left 
> 
., THEN GOTO 
~et~y; 
ELSE 
DO; 
msg.status=time$out; 
msg. actual=0; 
GOTO quit; 
END; 
END; 
msg.status=0; 
stat=set$m$inte~~upt(base$ad~,queue$token,data$availabIe 


CALL 
~qsend(msg.~esp$ex,msg$pt~); 
END; /* of do fo~eve~ 
*/ 


CODE AREA SIZE 
VARIABLE 
AREA SIZE 


MAXIMUM 
STACK SIZE 


198 LINES 
READ 


o PROGRAM 
ERROR(S) 


0159H 
0000H 
0019H 


3450 
00 
250 


1 
2 
3 
4 
5 
U7 
128 
129 
130 
131 
132 
133 
134 


SOURCE 
STATEMENT 


NAt1E 
CfG544 
CSEG 
PUBLIC 
RQRATE 
RQRATE: 
DW 
8 
$NOLIST 
$LIST 
$NOGEN 
NTASK 
SET 
0 
NEXCH 
SET 
0 


135 
136 
191 
246 
247 
248 
249 
253 
251 
255 
256 
264 
265 
266 
267 
274 


--------j 
STD 
STO 


IT 
CREATES 
EVERYTHING 
ELSE 
IT 
NEEDS. 
II'HT54, 200,1,0 
LINECH.64,130,0 


CR'rAB 
END 


PUBLIC 
3YMi30LS 
RQCRTB 
C 
0026 
RQRATE 
C 
0000 


EXTERNAL 
SYMBOLS 


INI'r54 
E 
0000 
LINECH 
E 
0000 
RESPEX 
E 
~Hl00 


USER 
SYMBOLS 


CRTAB 
+ 0000 
GENTO 
+ 
0000 
lET 
C 
0024 
INIT54 
E 
0000 
INTXCtI + 
0000 
ITT 
C 
0002 
LINECti 
E 
0000 
NEXCH 
A 
0001 


NTASK 
A 
0002 
PU8XCH 
+ 
0007 
RESPEX 
E 
0006- 
RQCRT8 
C 
0026 


RQRATE 
C 
0000 
STO 
+ 
0000 
TDBASE 
0 
0108 
XCH 
+ 
0005 


XCHAOR 
+ 
0002 


APPLICATION 
NOTE 


inter 


With the reduced 
cost of computers 
brought 
about 
by the 
advances 
in silicon-based 
computer 
components, 
com- 
puters 
have become 
distributed 
throughout 
offices 
and 
factories. 
The decentralization 
of the computing 
facilities 
is far from complete, 
and one significant 
impediment 
is 
the exchange 
of information 
amongst 
these distributed 
computers. 


Intercomputer 
communications 
can be divided 
into three 
groups: 
global, 
local, and bus communications!') 
Global 
refers 
to those 
facilities 
which 
are capable 
of spanning 
large 
distances. 
Local 
communications 
span 
smaller 
distances, 
generally 
limited 
to one building 
or one small 
group of buildings, 
and provide 
higher performance 
than 
global networks. 
Bus communications 
span even smaller 
distances 
(within 
a single 
computer) 
and 
provide 
even 
more 
performance. 


One 
intercomputer 
communication 
method, 
Ethernet, 
developed 
jointly 
by Digital 
Equipment 
Corporation, 


Intel Corporation 
and Xerox 
Corporation 
provides 
the 
facilities 
for the local communications 
group!" 
211This 


communication 
method 
is exactly defined 
by the Ethernet 
Specification 
V 1.0!1l) 


This Application 
Note provides 
information 
on Ethernet 
and the first Intel-supplied 
products 
for use of Ethernet. 


The note also addresses 
the software 
which must be sup- 


plied by the customer 
to effectively 
use the new Ethernet 
capabilities. 
Specifically 
the following 
topics are covered: 


• 
A brief overview 
of the Ethernet 
Specification 
• 
A discussion 
of performance 
characteristics 
of 
Ethernet 
• 
Expected 
usage of Ethernet 
in the office and 
factory 


• 
An overview 
of the iSBC 550 Ethernet 
Controller 
• 
The measured 
characteristics 
of the iSBC 550 
Ethernet 
Controller 
in the laboratory 
• 
A test in an electrically 
noisy environment 
• 
A description 
of an application 
which is typical 
of software 
to be provided 
by the customer 


The reader 
will be able to assess the development 
effec- 
tiveness and cost of the use of the iSBC 550 Ethernet 
Con- 
troller 
in a system 
design. 


Intel provides 
an implementation 
of the Ethernet 
Speci- 
fication with the iSBC 550 Ethernet 
Communications 
Con- 


troller. 
This controller 
is a full-featured 
implementation 
of the specification 
and is effective 
both 
for evaluating 
Ethernet 
and for early introduction 
of Ethernet 
products. 
The controller 
can be integrated 
into MULTlBUS-based 
systems. 


We chose the new System 86/330 
microcomputer 
for in- 
tegration 
with the iSBC 
550 Ethernet 
Controller. 
This 
System is representative 
of the kinds of systems expected 


on an Ethernet 
network. 
Further, 
the System 86/330 
pro- 
vided 
the 
tools 
necessary 
for 
the 
development 
of an 
Ethernet 
applieation 


The applieation 
chosen 
for demonstration 
of Ethernet 
fulfilled 
two requilements. 
First, it provided 
a typical and 
useful funetion. 
Second, 
it provided 
an example 
of multi- 


vendor 
interconnection 
using 
Ethernet. 
The 
result 
of 
ereating 
the Ethernet 
applicatIOn 
is a quantified 
measure 
of the effort 
necessary 
for multivendor 
interconnection. 


The 
iSBC 550 Ethernet 
Controller 
IS supported 
by the 


E-Driver. 
The 
E-Driver 
is software 
which 
provides 
a 
standard 
system 1/0 Interface 
for the iRMX 86 OperatIng 


System. 
The E-Driver 
uses the iMMX 
800 MULTIBUS 
Message 
Exchange 
software 
for communIeation 
with the 


Ethernet 
controller. 
A flexible and modular 
system can be 
constructed 
from the integration 
of standard 
Intel single 


board 
computers, 
a memory 
board, 
an iSBC 550 Fthernet 


Controller, 
the iMMX 
800 MULTlBUS 
Message 
Ex 


change, the iRMX 86 OperatIng 
System, and the E-Driver 


The Ethernet 
Specification!IlJ 
developed 
as a joint 
effort 
by Digital Equipment 
Corporation, 
Intel Corporation 
and 


Xerox 
Corporation, 
is a result 
of earlier 
experimental 
work done by Xerox!2, 
13,201 This work is based on a need 
for a high-speed 
interconnect 
of large numbers 
of com- 


puters. 
Further, 
the network 
must be easy to reconfigure 
and immune 
to total network 
failure caused by single com- 
ponent 
failure. These ambitious 
goals led to an experimen- 
tal network 
which 
has been operated 
successfully 
since 


1972. 


Ease of reconfigurability 
of a network 
is important 
in of- 


fice environments 
and those factory 
environments 
which 
continually 
add, 
delete 
or reconfigure 
their 
shop 
floor 
plan. Non-technical 
osers will remove network 
devices and 
transport 
them to another 
location. 
Such activities 
should 
not disrupt 
the remaining 
part 
of the network. 


One important 
goal often 
forgotten 
by implementors 
of 
networks 
is simplicity. 
The implementations 
should 
be 
easy to understand 
and devoid 
of marginally 
useful 
fea- 


tures. 
In achieving 
this goal, 
the network 
must 
remain 
flexible 
and 
not 
impose 
restrictions 
that 
reflect 
only a 
narrow 
application 
focus. Ethernet 
achieved this goal with 
the 
Carrier 
Sense 
Multiple 
Access/Collision 
Detect 
(CSMA/CD) 
access method. 


The CSMA/CD 
access method 
is conceptually 
simple, the 


exact same interface 
exists in all nodes, 
and the algorithm 
readily lends itself to VLSI solutions. 
These characteristics 


are being recognized 
as exemplified 
by the effort to stand- 
ardize 
Ethernet. 


The Ethernet 
Specification 
defines Ethernet 
exactly to en- 
sure 
that 
hardware 
and 
software 
developed 
by various 


inter 


manufacturers willbe compatible with those developed by 
all others. This is a significant advancement in data com- 
munications where few standards have been written and 
none implemented exactly. 


Multivendor acceptance and implementation of Ethernet 
provides a significant first step to an open system imple- 
mentation of a communications facility. However, addi- 
tional software not specified by the standard is required 
before a total system solution is possible. 


Most networks are structured into layers to reduce the 
complexity of implementation. The most successful struc- 
turing is that proposed in the ISO Reference Model for 
Open System Interconnect!!l! This model is commonly 
used for implementing networks because it partitions the 
solution to network problems into understandable entities. 
Each entity is both comprehensive and cohesive. 


The model is briefly described as follows: 


ISO Model Layer 
7. Application 
Primary Function 
• All possible uses of lower 
layers, virtual file, virtual ter- 
minal, file transfer, job control, 
etc. 


• Procedure call structure, code 
set, data structure 


• Binding of distributed functions 


• End-to-end transport of data, 


flow control, reliability, multi- 
plexing 


• Intermediate nodes, multi- 


plexing 


• Recovery from high error rate 


media 


5. Session 


4. Transport 


• Electrical, mechanical, and pro- 
cedural characteristics of media. 


The Ethernet Specification is organized as an architectural 
design, (seeFigure 2-1) corresponding to the lowest layers 
of the ISO Model for Open Systems Interconnect!!l. 
26) 


The specification defines two layers: data link layer and 
physical layer. The data link layer defines a communica- 
tion facility for the sending or receiving of data frames 
which is independent of the actual physical medium. The 
physical layer provides a physical channel through a coax- 
ial cable medium. 


I 
ETHERNET CONTROLLER 
BOARD 
~ 


I 
TRANSCEIVER 
CABLE 


inter 


The client layer is defined as higher levels of network ar- 
chitecture not defined by the Ethernet Standard. 
This 
layer may consist of the additional layers specified by the 
ISO Model. The client layer uses the data link and physical 
layers to transmit and receive frames or error status. 


The data link layer provides two main functions. First, it 
provides data encapsulation which handles frame address- 
ing, frame-cheek-sequence generation and verification, 
and frame delimitation. Second, the data link layer pro- 
vides link management which handles the access to the 
physical channel and handles resolution of conflicts. 


The frame format of the data link layer is shown in Figure 
2-2. It consists of a destination and source address, a type, 
data, and a frame-checking sequence. The destination ad- 
dress field of an Ethernet frame may be either a physical 
address uniquely assigned to each particular station on the 
Ethernet or a multicast address. The multicast address is 
associated with a group of logically related stations. A sta- 
tion may be a member of more than one multicast group. 
One predefined multicast address, the broadcast address, 
is associated with all stations on a given Ethernet. The sta- 
tion's physical address isdistinct from the physical address 
on any other station on any Ethernet. 


Station and multicast addresses are assigned and admin- 
istered by Xerox for a nominal fee!"1The source address 
is the physical address of the sending station and is pro- 
vided for use by the client layer. 


The type field is reserved for use by the client layers to 
identify a particular client layer protocol. The type field 
values are also administered by Xerox Corporation for a 
nominal fee. It is not interpreted by the data link layer. 
The data field consists of a sequence of n octets, where 
46<n < 1500. An octet ica set of 8 bits. Any arbitrary se- 
quence of octet values may appear in the fields. The 
frame-checking sequence is a 32-bit cyclic redundancy 
code computed 
as a function of the contents 
of the 
destination, source, type and data field. 


2.1.2 
FRAME TRANSMISSION 
AND 
COLLISION 
RESOLUTION 


The data link layer monitors the carrier sense signal pro- 
vided by the physical layer for channel busy. When the 
channel is busy, any transmission is deferred until the 
channel is no longer busy. The data link layer continues 
to defer for 9.6 microseconds to ensure a standard inter- 
frame spacing which provides an interframe recovery time 
for other data link controllers. 


It ispossible for two stations to begin transmission at near- 
ly the same time. This contention for the network can oc- 
cur only within the short time required for a single station 
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to acquire 
the network. 
(All other stations 
detect carrier 


sense.) The data link layer detects collisions 
by monitor- 
ing the collision-detect 
signal 
provided 
by the physical 


layer. 
Upon 
detection 
of a collision, 
transmission 
con- 


tinues 
for at least 32 but not more than 48 bits to ensure 


collision 
detection 
by all other 
stations. 
The time to ac- 
quire the network 
is dependent 
on the propagation 
speed 


of the electrical signal in the coaxial cable (O.77c worst case 
where 
c is the speed of light), 
the propagation 
speed in 
transceiver 
cable 
(0.65c 
worst 
case), 
the lengths 
of the 


cables, 
and the number 
of repeaters. 
The worst-case 
time 


to acquire 
the network 
is 45 microseconds. 


When a transmission 
has terminated 
due to a collision, 
it 
is retransmitted 
until successful 
or until 16 attempts 
have 
been made. 
All attempts 
to retransmit 
a frame 
are com- 


pleted 
before 
a subsequent 
frame 
is transmitted. 
The 


retransmission 
of frames 
experiencing 
a collision 
is con- 
trolled 
by selection 
of a random 
delay interval. 
The delay 


algorithm 
provides 
a graceful 
and fair access method 
for 


a station 
during 
peak loading. 


The algorithm 
is graceful 
because 
it reduces the through- 
put experienced 
by a station 
in small increments. 
Anyone 


station will not experience 
a long delay where it is excluded 
from requesting 
network 
access. 
Thus 
a station 
may be 


perceived 
to run slower but it does not unexpectedly 
stop. 


The algorithm 
is fair since it permits all stations 
on the net- 


work to bid for network 
access with equal priority. 
A sta- 
tion may clect to us 
a less aggressi\e 
attempt 
to access the 
network 
but it is not required 
to do so. The algorithm 
en- 
sures high network 
usage with access evenly distributed 
to 


all requesting 
stations. 


Frame delimitation 
is provided 
by the carrier sense signal 


from the physical layer. The data link layer accepts frames 
with the destination 
equal 
to the physical 
address, 
the 


broadcast 
address 
or any of the set of multicast 
addresses 
to which this station 
belongs. 
If a frame-ched.-sequence 


error is detected, 
the frame is discarded. 
The client layer 
protocols 
are respon.,ible 
for all end-to-end 
delivery 
en- 


surance 
and must 
detect 
the need to retransmit 
frames 
discarded 
duc to frame-cheek-sequence 
errors. 


Frames 
which 
are shorter 
than 
the minimum 
are dis- 
carded. 
Frames 
which are longer than the maximum 
may 
be discarded 
or truncated. 
If a frame does not contain 
a 
multiple 
of 8 bits, it is truncated 
to the last complete 
octet. 


The physical 
layer of the Ethernet 
Specification 
is a base 


band, coaxial cable system. The physical channel is the im- 
plementation 
of the physical 
layer and is fully specified 
in 


the specification 
to ensure compatibility 
across manufac- 


turers. 
The channel 
consists 
of a coaxial 
cable, 
a trans- 


ceiver, 
and data encoder/decoder. 
Repeaters 
are used to 
reach 
the maximum 
allowable 
distances 
and to provide 
topological 
flexibility. 
Three configurations 
of Ethernet 
are given in Figure 
2-3,2-4 
and 2-5. 


The cable 
specifications 
are intended 
to ensure 
proper 
operation 
of the Ethernet 
in its varied 
topologies. 
The 
cable 
is a robust, 
double-shield 
coaxial 
cable 
which 
is 


suitable 
for installation 
in office or factory 
environments 
such as dropped 
ceilings, 
raised floors and cable troughs. 
The 
cable 
was chosen 
to provide 
acceptable 
reflection 
characteristics 
caused 
by transceivers 
or connectors 
and 
to provide 
adequate 
noise 
shielding. 
BELDON 
AWM 
STYLE 
1478 ETHERNET 
COAX 
IE is one commercially 
available 
cable that meets the Ethernet 
Specification. 


The cable is terminated 
at both ends to provide 
matching 
termination 
impedance 
to reduce reflections 
from the ends 


of the cable. The network 
will not operate 
without 
these 
terminations. 
Connectors 
are defined 
by the standard 
for 
joining 
more than one segment 
into a single, 
electrically 
continuous 
segment. 


The data 
link controller 
is coupled 
to the cable 
by the 
transceiver. 
The transceiver 
interface 
transfers 
data 
be- 
tween the coaxial 
cable and the controller, 
indicates 
the 
presence 
of a collision, 
and optionally 
provides 
power to 
the transceiver. 


The 
transceiver 
may 
be attached 
to the 
cable 
with 
a 
pressure 
tap. Such a tap is installed 
by cutting a small hole 
in the outer jacket 
and cable shield and pushing 
a pointed 
electrical 
connector 
into contact 
with the central 
conduc- 
tor. This tap can be installed 
without 
cutting 
the coaxial 
cable 
and does 
not interrupt 
network 
service 
for other 
stations. 


A transceiver 
may also be attached 
by cutting 
the coaxial 
cable and attaching 
connectors 
to each piece of cable. The 
connectors 
are then attached 
to the transceiver. 
The elec- 
trical 
connection 
of the cable to the transceiver 
logic is 


then internal 
to the transceiver. 


The taps and transceivers 
offered 
by Intel or by TCL Cor- 
poration 
and 3COM 
Corporation, 
both of Santa 
Clara, 


are examples 
of commercially 
available 
compatible 
de- 
vices. 


The transceiver 
provides 
the electrical 
isolation 
between 
the controller 
and the cable to control 
noise and avoid cur- 
rent flow through 
the cable shield. 
This is an important 
safety and reliability 
factor which enhances 
network 
avail- 
ability 
after 
failure 
of individual 
stations. 
Transceivers 
may be placed 
at any of the regular 
2.5 meter 
spacing 
marks on the coaxial cable and up to 100 transceivers 
may 


exist on anyone cable segment. These restrictions are in- 
tended to reduce insertion reflections. 


If the transceivers are to be separately packaged from the 
data link controller, a cable of up to 50 meters may be 
used. The cable consists of four-stranded, 
twisted pair 


conductors with a shield and insulating jacket. The con- 
nectors are also specified in the Standard. 


The clock and data are encoded into a single, self-clocking 
serial data stream. The encoder drives the transmit pair 
of transceiver cables using Manchester Encoding. The 


data is preceded by a preamble to allow channel circuitry 
throughout 
the network to reach a steady state before 


receiving valid input. The decoder removes the preamble 
and provides output clock and data from the transceiver 
cable receiver pair. 
' 


The topology of a network may be extended by adding 
repeaters which propagate signals from one cable segment 
to another. A maximum of 2 repeaters may be in the signal 
path between any two transceivers. Only one path may 
exist between any two transceivers. The repeaters must 
propagate both data signals and collision detect signals. 


t 
TRANSCEIVER 
& CONNECTION 
TO COAXIAL 
CABLE 
(100 MAX PER SEGMENn 


of maximum 
capacity 
when large block sizes (512 bytes) 


are transferred, 
even for peak loads!20! 
The 
10 megabits 
per second 
speed 
of the physical 
level 


determines 
the maximum 
capacity 
of Ethernet. 
This max- 
imum is reduced 
by the requirements 
for frame encoding, 
minimum 
delays, 
and collision 
resolution. 
The theoret- 


ical'l. 
14,16,22.251and 
measured 
18,201characteristics 
of 


Ethernet or Ethernet-like 
networks are already documented. 


The utilization 
of the network 
can be kept at levels of 95010 


When network 
demand 
exceeds the capacity 
by more than 


100%, the CSMA/CD 
access method 
has been shown to 


allocate 
the network 
fairly to various 
stations!l] 
Anyone 
station 
experiences 
a lower 
average 
throughput 
than 
it 
would otherwise 
expect. Well engineered 
networks 
would 
be configured 
to expect an average 
total load well below 


intel 


the maximum 
(40-80070). 
Peak loading 
would then be of 


a bursty 
nature 
and easily handled 
by Ethernet. 


The 
selection 
of Ethernet 
for a particular 
application 
would be in response 
to requirements 
for high-speed 
com- 
munications 
between 
computers. 
One reason 
for com- 
puter interconnection 
is to share high-speed 
(or high-cost) 
devices such as laser printers 
or streamer 
tapes. 
Another 
reason 
is the sharing 
of common 
data bases, 
such as files 
contained 
on a disk 
system. 
The 
data 
rates 
for these 
devices determine 
the interface 
requirements 
and network 
throughput 
rates. 


The following 
performance 
numbers 
are representative 
of 
devices commonly 
considered 
for attachment 
to Ethernet: 


Device 


I. 
Winchester 
Disk 


2. Streamer 
Tape 


3. Printer 


4. Floppy 
Disk 


5. CRT (workstation) 


Average 
Throughput 


800K 
baud 


800K 
baud 


500K 
baud 


250K 
baud 


10K baud 


An Ethernet 
station able to operate at an average through- 
put in excess of these averages 
could 
be used effectively 
as controllers. 
Applications 
with a total average network 
throughput 
demand 
of less than the 10 megabits 
per sec- 
ond are ideally 
suited. 
Further, 
such applications 
allow 


fair and graceful 
access during 
peak load situations. 


Related 
to throughput 
is the issue of average 
response 


time. 
In some environments 
it is critical 
to ensure 
that a 


command 
and response 
can be exchanged 
in a fixed inter- 
val. The Ethernet 
access method 
is probabilistic 
because 


of the possibility 
of a collision 
occurring. 
Automatically 
repeated 
access attempts 
reduce the probability 
of nonde- 
livery to an increasingly 
smaller value with each attempt. 


The frame will be declared 
undeliverable 
if 16 consecutive 
access attempts 
fail due to collisions. 
Thus, 
the sending 


station 
is notified 
if the network 
load is inappropriate 
for 


the chosen 
application. 
The maximum 
time for access or 
notification 
of nondelivery 
is related 
to the maximum 
block sizes permitted 
by the network 
and fixed network 


parameters. 
This maximum 
time can be a very large time. 


Other 
factors 
besides the access method 
playa 
role in the 


average 
response 
time. Environmental 
noise and the sta- 


tion receive window 
(see Section 
5) must be considered. 


In the presence 
of noise, there is a probability 
that some 
frames 
will be damaged 
and lost. Any station 
receiving 
a 
frame with a frame-check-sequence 
error discards 
it with- 
out further 
action. 
The client layer protocols 
must provide 
error 
recovery 
procedures 
with response 
timers 
and se- 
quence 
verification 
for detecting 
lost blocks. 
The maxi- 
mum response time possible before delivery or notification 
of failure 
is related 
to the client layer time-out 
value and 
maximum 
retry count. 


Finally, each receiving station may accept blocks at a burst 
rate much higher 
than its ability 
to process 
such blocks. 


Eventually, 
some limited resource within the receiving sta- 


tion 
will be consumed 
and 
subsequent 
data 
cannot 
be 


received until processing 
of prior data is completed. 
The 


receive station 
recovery 
time (or window) 
determines 
the 


period where a station 
would miss blocks addressed 
to it, 


thereby invoking 
time-out 
recovery at higher levels of pro- 


tocol. 
With respect 
to the ISO Model, 
the transport 
con- 


trollayer 
would be responsible 
for such time-out 
recovery. 


In an environment 
where 
response 
time is critical, 
the 


selection 
of Ethernet 
obligates 
the designer 
to consider 


sustained 
average 
load, 
peak 
load 
durations, 
time-out 


recovery 
interval, 
and receive station 
recovery 
time. The 


designers 
goal would be to avoid excessive collisions 
and 


lost blocks. 


Excessive 
collisions 
are avoided 
by keeping 
the average 


load to a value less than the maximum 
capacity. 
Loads of 


40070 to 80070 capacity 
will experience 
few collisions. 


Lost blocks are avoided 
by ensuring 
that transmissions 
to 
a receiving station do not exceed the rate at which they can 
be processed. 
This is usually accomplished 
by a flow con- 


trol acknowledgement 
packet provided 
by the client layer 
software. 
Further, 
the number 
of stations 
transmitting 
to 


a single receiving 
station 
must not exceed the number 
of 


frames 
that can be received 
back-to-back. 


4 ETHERNET* 
IN THE OFFICE 
AND FACTORY 


Interconnection 
of computers 
in the office 
has received 


considerable 
attention 
in the trade literature 
and vendors 


are supplying 
new products 
at an increasing 
rate!4. 5. 7. 19] 


Systems 
supporting 
shared 
data 
bases, 
electronic 
mail, 


shared 
peripherals, 
etc. are easy to analyze 
for perform- 


ance requirements. 
In the office, 
other non-obvious 
con- 


siderations 
are as important 
as the final user application. 


First, 
an office 
network 
must be immune 
to inadvertent 


network 
interruption. 
That is, the electrical 
failure (short- 


ing or grounding) 
of a transceiver 
or controller 
must not 


cause failure of the network. 
Electrical 
spikes on the cable 


must not destroy 
the attached 
transceivers 
or stations. 


Second, 
the network 
must be easy to configure 
or recon- 


. figure. Nontechnical 
office workers 
must be able to move 


a station 
from 
one physical 
location 
to another. 
The 


physical 
location 
should 
be transparent 
to the user ap- 


plication 
supplied 
by the station. 


Third, 
the network 
must provide 
a level of performance 


for expected 
applications 
and for future 
uses. Growth 
of 


the office 
and addition 
of higher 
performance 
stations 


must be considered. 
Even the requirements 
for real-time 


data 
such as voice or video must be considered. 


inter 


Finally, networks selected for the office must eventually 
achieve widespread and multivendor support. This ensures 
the continued development of products and continued ef- 
fort to reduce the connection costs. Certainly, an accep- 
table network must be accessed using single VLSI silicon 
chips to allow very low cost interconnect. 


Ethernet fits the office requirements very well. The design 
is flexible and permits widely varied uses. The successful 
effort to standardize Ethernet will enhance the usefulness 
of a VLSI solution for Ethernet and make connection 
more cost effective. 


In the factory, 
applications 
are more likely to have 


distributed sampling and decision making characteristics. 
In such environments, real-time responses, reliability and 
noise immunity are important factors. Ethernet can be 
used in the factory environment where noise is reduced to 
the levelsstated in the Specification and load levelsare suf- 
ficiently low to ensure a small probability of repeated col- 
lisions. However, concern for noise immunity of the net- 
work must be matched by similar concern for the station 
boards and components which are also susceptibleto noise. 


An Ethernet network carrying critical time-dependent 
data should not be carrying a full load of noncritical data 
since no priority scheme is provided. That is, there is no 
method assigning a higher priority for network access to 
a station with time-critical data. 


Ethernet has been specified to serve the greatest number 
of applications while retaining a conceptually simple algo- 
rithm. Ethernet does not provide some features which 
have been proposed for various local area .networks. It 
does not provide a method of allocating a guaranteed 
bandwidth to a specific station. Proposals to provide such 
a feature have been made for various alternative net- 
works!" 
16, 22,2'1including the IEEE 802 committee pro- 


posal. These generally involve alternative backoff algo- 
rithms or the passing of a token to signal the access of the 
network. 


These alternatives avoid the problems of random delays 
due to collision resolution. The problems of noise, time 
out resolution, and receiving window remain. 


The IEEE 802 proposal defines a deterministic system in 
terms of the absence of noise!!4]The guaranteed access in 
the absence of noise is achieved with increased complexi- 
ty of the individual station's access algorithm. Methods 
must be provided for initial startup or recovery from a lost 
token and for detection and removal of duplicate tokens. 
Further complexity is added by the negotiation for alloca- 
tion or refusal of requests for guaranteed bandwidth. 


Ethernet ensures multivendor compatibility of all Ethernet 
implementations by not providing optional features. This 
results in all stations being compatible on all Ethernet net- 
works everywhere.The advantage of this feature is superi~r 


to the advantages of features such as variable bit rates or 
variable address lengths. 


5 THE iSBC@550 ETHERNET· 


COMMUNICATIONS CONTROLLER 


Intel's first OEM product for Ethernet provides an inter- 
face for MCS-85, iAPX 86, or iAPX 88-based microcom- 
puter systems. The controller is a powerful and full- 
featured implementation of the Ethernet Specification. 


The controller consists of two boards; a processor board 
and a serial/deserialization (SERDES) board. The proces- 
sor board incl.udesfirmware for the packet management 
to the data link layer and communication with a system 
processor board. The serialization/ deserialization board 
performs most of the functions specified in the Ethernet 
Specification. 


The processor board contains a 5 MHz 8088CPU and 8K 
bytesof firmwarefor the data linklayerand the MULTIBUS 
Interprocessor 
Protocol 
(MIP)1281 implementations. 


Communications between Ethernet processor board and 
the system processor board (iSBC 86/I2A, 86/30, etc.) is 
accomplished via MULTIBUS memory. (SeeFigure 5-1). 


The Ethernet data link layer is accessed and controlled by 
software in the host system by the External Data Link 
(EDL) layer. This software appears as a protocol bridge 
since the higher level client layer software cannot direct- 
ly access the Ethernet data link layer. The processor board 
also provides packet encapsulation 
for packets to be 


transmitted. 


Two other methods of communication are also used be- 
tween the system and controller processor boards. First, 
the Ethernet processor board contains a jumper selectable 
base address of a MULTIBUS memory block where ini- 
tialization information is to be exchanged. Code in the 
system processor must be configured to use the initializa- 
tion addresses expected by the iSBC 550 Ethernet Con- 
troller. Second, a configurable controller wakeup address 
(I/O port address) is selectable by jumpers on the Ethernet 
processor board. The host processor board uses this ad- 
dress to interrupt the iSBC 550 Ethernet Controller when 
a command is available. 


The Ethernet processor board executes the commands 
received by the External Data Link (EDL) layer. Data to 
be sent is moved to static RAM on the processor board 
from MULTIBUS memory specified by EDL commands. 
Received data is moved from on-board static RAM when- 
ever MULTIBUS memory is made available by an EDL 
command. 


The processor board contains 8K of static RAM for 
transmission and receipt of Ethernet frames. This memory 


inter 


is divided into 4 buffers 
of 2K each. One buffer is 
allocated for transmission of a frame and three allocated 
for receipt of frames. These buffers are used to avoid con- 
tention with access to MULTIBUS memory from other 
boards in the system. 


For transmission 
of a frame, 
data is moved from 


MULTIBUS memory specified by an EDL command to 
the static RAM buffer. DMA memory transfers are per- 
formed by the SERDES board during the actual transfer 
to the cable. 


Up to 3 frames can be received before the static RAM is 
filled. Once filled the data in the static RAM must be 
moved to MULTIBUS memory specified by an EDL com- 
mand. While the static RAM is full and data is being 
copied to MULTIBUS memory, any frames destined for 
this station will be lost. The small window where the con- 
troller is not accepting incoming frames is resolved by 
client layer flow control procedures. 


The iSBC 550 processor boardprovides 
16Kof dynamic 
RAM which can be loaded from the system processor. 
This memory is provided for support of higher layers of 
network software such as the ISO session, transport and 
network layers. This feature is not currently offered for 
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OEM usage of the iSBC 550Ethernet Controller but is ex- 
pected to be used when Intel Development Systems are in- 
terconnected 
via Ethernet. 
Any client level software 


developed for the iSBC 550 Ethernet Controller should be 
designed with strict separation of the ISO layers, par- 
ticularly between presentation and session. The user is 
thereby better prepared for evolution of Ethernet products. 


The SERDES board performs the serialization/deseriali- 
zation, framing, frame-check-sequence generation and 
checking, Manchester encoding and decoding, address 
recognition and all CSMA/CD 
link access protocol func- 


tions. Data is sent or received by DMA access to the static 
RAM on the processor board. 


The Model 675 Development System for Ethernet pro- 
vides the user with the tools necessary to develop and test 
communication software and applications which will use 
Ethernet 
as a communications 
method. It contains a 


MULTIBUS Ethernet Controller, a 10-meter cable for 
connecting model 675s, and an Ethernet Data Link layer 
software library. The library contains an implementation 
of the MULTIBUS Interprocessor Protocol (MIP) and 
EDL interface modules to simplify the user interface to 
Ethernet. 


EDL 
I 


~ 
~ 
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The Model 677 DS/E Ethernet upgrade kit for Intellec 
Development Systems provides the Series 11/85 or Series 
III user with the additional tools necessary to develop and 
test software that will use Ethernet. 


For target systems, the iRMX Operating Systems are ideal 
for a great varietyof situations.The iMMX 800MULTIBUS 
Message Exchange Software 
(28) is the standard 
iRMX 
Operating System implementation of MIP and may be 
used for communication with the iSBC 550Ethernet Con- 
troller. When the iRMX 86 Operating System is used, a 
standard driver, the E-Driver, is provided for the Basic 
I/O system. The E-Driver performs the initialization pro- 
cedures for the iSBC 550 Ethernet Controller and allows 
the client layer to use the standard iRMX 86 I/O system 
interface. 


The interface offered by the iRMX 86E-Driver is not iden- 
tical to that offered by the Model 675 Development 
System. This is expected due to the different system archi- 
tectures. Designs of client layers should isolate the inter- 
face requirements for lower layers from the bulk of the 
software supporting the higher level protocol. This design 
practice eases the integration of future Ethernet develop- 
ments. 


Support of the Ethernet specification on a single VLSI 
silicon component may result in new interface specifica- 
tions for the client layer software. The new component 
may offer enhanced features which will be offered in the 
EDL of a new controller supporting the component. One 
significant 
feature is the ability to chain small non- 


contiguous 
receive buffers for the reception of large 


frames. 


The VLSI Ethernet component may also be located on the 
same board as the system processor which would present 
a considerable 
interface 
change from the iSBC 550 


MULTIBUS interface. These new interfaces will be made 
available to the client layer software in future products. 
Thus it is important to design systems which can accom- 
modate changes in the data link layer interface. 


With time the communications 
industry will settle on 


standard protocols for higher layers of the ISO Model. 
Already there is considerable chance that various stand- 
ards organizations will settle on a specification for their 
ISO transport control layer )9, 10,241 


It also seems possible that several protocols will exist for 
each ISO layer to deal with the unique problems of specific 
applications. A good example of two equivalent but quite 
different lower layer protocols is the CCITT X.25 proto- 


COPI7) and the Ethernet protocol. The client layer selected 
for each might be quite different when used in an applica- 
tion most suited to the chosen lower layer protocol. 


To anticipate future development in higher layer pro- 
tocols, client layer software must be designed with strict 


adherence to the definitions of the ISO layers. FUrther, the 
layer boundaries must be engineered to eliminate tight 
dependencies between implementations of each layer. 


The iSBC 550Ethernet Controller is a powerful and full- 
featured implementation of the Ethernet Specification. Its 
intent is to provide a development tool for the verification 
of client layer software. With the future availability of the 
VLSI Ethernet component, client layer software can be 
ported to the target systems. 


For systems which must be operational before the VLSI 
component is available, the iSBC 550 Ethernet Controller 
i&fully capable of providing the Ethernet function. Stand- 
ard iSBC board level products can be used to create com- 
plete systems which use Ethernet to communicate without 
long development times. With the System 86/330, a com- 
plete microcomputer system, development time can be 
reduced even more. Addition of the iMMX 800 software 
and the iRMX 86 E-Driver permits the engineering focus 
to be on the client layer software and the user application. 


It is easy to get started with Ethernet using the iSBC 550 
Ethernet Controller and System 86/330. Intel's commit- 
ment to providing the board level and component level 
products permits the user to buy or build as appropriate. 
Moreover, Intel's commitment to Ethernet will ensure 
future Ethernet products. With the availability of the 
VLSI Ethernet component, a single board computer can 
support Ethernet much like the serial or parallel ports on 
today's single board computers. This will result in very 
low cost attachment to Ethernet. 


6 THE iSBC®550 ETHERNET* 
COMMUNICATIONS CONTROLLER 
IN THE LAB 


The theoretical performance of the Ethernet and Ethernet- 
like networks has been well known for several years. 


[1,16.22,25) 
Moreover, the performance of a real network 
has been studied [8, 20) and the theoretical model shown to 
be valid in those cases. Since the Ethernet Specification 
is not in doubt, the focus of this study is the integration 
of an Ethernet Station from standard Intel Products and 
measurements of certain performance characteristics. 


The System 86/330 (see Figure 6-1) was chosen as system 
processor because of the facilities for both development 
of software and the facilities for testing. The software was 
developed with standard tools available on the System 
86/330. The new software was then loaded into the System 
86/330 with the bootstrap utility. The 957B and iRMX 
Debug Monitor were then used to test and debug the new 
software. 


The experience with writing an Ethernet Application is 
presented in Section 8. The remaining information in this 
section presents the results of the performance tests. 


intel 


To understand the performance of the iSBC 550 Con- 
troller, three measurements were proposed: 


• The rate at which a station could present data to 
the Ethernet was measured to determine if 
receive window closure could be caused by a 
single uncontrolled station. 


• 
The rate of reliable data exchange was measured 
for analysis of the controller performance in a 
resource server. 


• 
The round trip response time for reliable data ex- 
change was measured for analysis of controller 
performance in real-time control environments. 


A test program was written to obtain the three measure- 
ments. In addition the program was to run as an iRMX 
86 task to measure the performance of standard products 
and to run as a custom system. This objective was achieved 
by structuring the test program into layers. 


The test program consisted of three modes: output only, 
initiator and responder. In each case, the data in each out- 


put buffer was preset, and thus does not include applica~ 
tion processing overhead. The program would periodically 
request statistics from the iSBC 550 Ethernet Controller 
and create a display of various statistics. 


In output only mode the station would transmit data into 
the network at the maximum rate possible. Any received 
input data is discarded. This test was to determine if the 
receive window, as discussed earlier, could be closed by 
a single station. In fact, when a second station was set up 
to receive this continuous output, nearly half the blocks 
transmitted were lost due to window closure. 


The initiator and responder were created to measure the 
rate of reliable data transfer which could be achieved 
without causing window closure. The initiator will send 
a packet with a specific sequence number. Upon receipt 
of a response with the expected sequence number the ini- 
tiator would send another packet with the next available 
sequence number; 
modulo 2** 16. The initiator 
can 
transmit more than one block in sequence before requir- 
ing acknowledgement. The number of blocks outstanding 
could be varied for the test. 


iSB~ 
215 DISK CONTROLLER 


iSBX'· 
218 FLOPPY 
DISK CONTROLLER 


--B 


TCL 
TRANSCEIVER 
AND TAP 


BELDON 
COAX 
CABLE 


0---0 
\ 


WD: 
WINCHESTER 
DISK (35 M BYTE) 
FD: 
FLOPPY 
DISK; DOUBLE 
DENSITY/DOUBLE 
SIDE (.5 M BYTE) 


CRT: 
HAZELTINE 
1510 @ 9.6K BAUD 


iSBG« 056: 
256K BYTE MEMORY 
BOARD 


inter 


Whenever 
a response 
is received out of order, the response 
is discarded. 
Either the original 
block or the response 
was 
lost for the expected 
sequence 
number. 
No special reject 
logic 
was implemented. 
Lost 
blocks 
are recovered 
by 


retransmission 
after 
an acknowledgement 
timeout. 


The 
responder 
would 
always 
echo 
each 
received 
data 


block 
with 
a response 
of exactly 
the 
same 
size. 
The 


response 
carries the same sequence number 
as the original 


block. 
No check is made to ensure 
the block is received 


in order 
nor is a reject response 
sent for out-of-sequence 


errors. 
Such a check would be required 
if the received data 


must be processed 
in correct 
sequence. 


The 
first results 
measured 
the performance 
obtainable 


with standard 
software 
and hardware: 


• 
System 
86/330 


• 
iRMX 
86 Operating 
System, 
Release 
4 


• 
iMMX 
800 MULTIBUS 
Message 
Exchange, 
Release 
2 


E-Driver 
(part 
of iMMX 
800 MULTIBUS 


Message 
Exchange) 
. 


The performance 
measured 
(see Figure 6-2 and Appendix 


A) was appropriate 
for a variety of expected 
network 
ap- 


plications 
(Section 
3). The client layer software 
has the 


powerful 
iRMX 
86 Operating 
System 
for support. 
Fur- 
ther, the iMMX 800 MULTIBUS 
Message Exchange 
soft- 


ware is available 
for use by the client layer software 
for 


tying together 
multiple 
processor 
boards. 
Thus, 
complex 


multiprocessor 
systems 
can be constructed 
which utilize 


the iSBC 550 Ethernet 
Controller 
and standard 
software. 
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Figure 6-2. Standard 
Software 
Throughput 
Results (two blocks in queue, 
1000 
byte blocks) 


The second results were obtained 
by replacing 
the Stand- 


ard Operating 
System software 
with a custom 
driver 
for 


the iSBC 550 Ethernet 
Controller. 
This driver consists 
of 


a version 
of the 
MULTIBUS 
Interprocessor 
Protocol 
(MIP) 
as specified 
in the iSBC 550 Programmers 
Refer- 
ence Manual. 
In this version the test programs 
did not use 


any iRMX 
86 System 
calls. 


The test results 
show that 
reliable 
data 
rates 
of up to 1 
megabit 
per second 
can be achieved 
using the iSBC 550 


Ethernet 
Controller 
(Figures 
6-3 and Appendix 
A). This 


is easily fast enough 
to support 
a wide variety of applica- 
tions. 
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Figure 6-3. 
Custom 
Driver Throughput 
Results 
(two blocks in queue, 
1000 byte 


blocks 


The results 
show that a station 
can transmit 
faster 
than 


anyone 
station could receive (Figure 6-3). This is expected 
due to the greater 
processing 
requirements 
for a receiver. 


The period where input data can not be received until prior 
data is processed 
was discussed 
earlier as the receive win- 
dow. With uncontrolled 
transmission, 
data rates fell and 


response times approached 
the lost frame time-out 
values. 


When the transmitting 
station 
was flow controlled 
by an 


acknowledging 
protocol, 
data 
rates 
were moderated 
by 


about 
80070 but response times were quite regular. 
Note the 


acknowledgements 
were exactly 
the size of the original 
command, 
i.e. an echo. 


Two 
response 
time calculations 
were made. 
First, 
each 
command/acknowledgement 
was timed 
and 
the max- 
imum 
reported. 
Second, 
the average 
was calculated 
for 
each 
10 second 
interval 
(500 to 1000 round 
trips). 
The 


average 
was verified 
using block 
counts 
in sending 
and 
receiving 
stations 
and wall clock times. 
Both the average 
and maximum 
values were reproducible 
and regular 
over 
long periods 
of time (20 minutes). 


The maximum response time represents the worst case 
round trip time for a message originating in one applica- 
tion, echoed by another application in a remote System 
86/330, 
and returned to the original application. This 
number is equivalent to the average response time in tests 
where only one block is allowed in the network. 


When two blocks are allowed in the network, the average 
time improves because overlapped processing can occur. 
That is, data blocks can be prepared and sent while prior 
data blocks are echoed in the remote system. When more 
than two blocks are allowed in the network, some get 
queued either locally or remotely, and this results in in- 
creased maximum response times. (SeeFigure 6-4 and Ap- 
pendix A). Queueing occurs, either locally or remotely, 
when a frame has been given to the Ethernet controller but 
has not yet been sent. It also occurs when a frame has been 
received by the controller but the frame has not been 
received by the applic.ation. 
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Figure 6-4. 
Custom 
Driver Response 
Time 


Results (1000 byte blocks) 


As a result of the measurements of the Ethernet controller 
in the System 86/330, 
additional tests were conducted by 
the Data Communications Software Development Group. 
These measurements were conducted with software probes 
to determine the time to perform various operations. The 
results of these tests are reported in Appendix B. A custom 
Ethernet data link interface was developed to use standard 
iRMX 86 interrupt and mailbox facilities. These results 
show a very high performance level achievable with the 
full availability of services of the iRMX 86 Operating 
System. 


The programs used to obtain these results can be obtained 
from the Insite Library. The programs are included wit4 
the application discussed in Section 8 and titled "Xerox 
File Transfer Facility!' 


7 A TEST IN AN ELECTRICALLY 


NOISY ENVIRONMENT 


The ability of Ethernet to operate in a factory environ- 
ment is sometimes questioned. A factory environment is 
usually described as one where various levels of electrical 
noise are expected. Since no actual tests have been pub- 
lished, we took our Ethernet test systems into the main 
equipment rooms where we had access to an arc welder, 
a large induction motor and several motors and gener- 
ators. 


Two simple tests were performed to evaluate the verbal 
criticism of Ethernet. These simple tests were only in- 
tended to demonstrate the use of Ethernet in one environ- 
ment which contained unspecified levels of electrical 
noise. Additional studies are needed to draw any conclu- 
sions from these tests since the results are not reproducible 
anywhere else but in our test site. 


The first test was to attempt to cause a failure of the 
Ethernet in an environment containing motors and gener- 
ators. The second test was to cause a failure by actively 
welding near the cables and transceivers. 


Our first test was to determine the error rate in our own 
development lab. The test system consisted of two System 
86/330s, 
two iSBC 550 Ethernet Controllers, 150 feet of 
coaxial cable, two 50 foot transceiver cables, and two 
transceivers. The response time test discussed earlier was 
run for 13.5hours without detecting a collision or a frame- 
check-sequence error. 


This same equipment was moved to the equipment room 
of our facility where there were several motors and 
generators. The coaxial cable, transceivers and transceiver 
cables were placed in the equipment room at close prox- 
imity to expected noise sources. No special effort was 
made to protect the cable or other devices from noise. 


The results in the equipment room surprised us after the 
experience in the development lab. The error rate was one 
damaged block for each 10,000 blocks transmitted (see 
Appendix A). 


One previously unknown characteristic of Ethernet is the 
immediate detection of frames damaged by noise by the 
collision detect logic. Only 12frames were lost during the 
3 hour test. These lost frames were all recovered by the 
client layer response time-out recovery logic. Most of these 
errors could have been recovered by a packet reject logic 
as found in Intel's Network Architecture transport layer 
protocol. 


The noise test was rerun with the transceivers and trans- 
ceiver cables outside the equipment room. The error rate 
dropped somewhat (see Appendix A). The transceivers 
and transceiver cables are not the sole source of noise in- 
duction. In harsh environments where noise immunity 


specificiations 
are required 
the cables can be protected 
by 
additional 
shielding 
such as conduit. 


To test Ethernet 
near an arc welder, 
we laid the coaxial 
cable around 
the welding table and placed both transceivers 
within 
10 feet of the welder. 
The coaxial cable was within 
3 feet of the arc and within 
6 inches 
of the high voltage 
leads. 
This physical 
configuration 
was arbitrary. 


The first test failed 
when the operator 
inadvertently 
al- 
lowed the high voltage 
cables to touch 
the coaxial 
cable. 


Inadequate 
grounding 
of the coaxial 
cable 
lead to the 


failure of both CPU boards. 
However, 
both systems were 
immediately 
reloaded 
and no damage 
was done 
to any 
component. 


A moderate 
error rate was present 
on the cable but there 


was no evidence 
that welding caused any induced 
noise in 


this configuration. 
Both AC and DC welding 
were tried, 
each for about 
5 minutes. 
In each case the currents 
were 


so high that the arc was too hot for most welding 
needs. 
In any case, we could not disrupt 
the network 
with the arc 
welder 
under 
these conditions. 


These simple tests demonstrate 
that at least one configura- 


tion can be successfully 
supported 
by Ethernet 
in a noisy 
environment. 
Additional 
testing 
would 
be required 
to 
draw any conclusions 
about 
any other general 
situation. 


The selection and use of a local area network 
must depend 


on the user application. 
One of the common 
concerns 
of 


customers 
is the amount 
of effort 
to implement 
various 
network 
protocols 
and common 
network 
applications. 


To understand 
this concern, 
we chose to implement 
the 


Xerox protocols!6 .•2)since they demonstrate 
multivendor 
interconnect 
ability. 
These protocols 
are only one of sev- 


eral choices 
which 
are available 
to network 
developers. 


The 
Intel 
network 
products 
1191offer 
protocols 
which 


allow access to file servers, print servers and development 
systems. 
Eventually, 
Intel will offer data base managers 


and other 
commercial 
applications. 


Several vendors 
have selected the Department 
of Defense 


Protocol!9. 
10) which 
is compatible 
with Arpanet 
and is 
becoming 
an industrial 
standard. 
The European 
Com- 


puter Manufacturers 
Association 
(ECMA) Transport 
Pro- 


tocol is another 
choice which will be effective 
in Europe. 
Proprietary 
network 
protocols 
of mainframe 
and mini- 


computer 
manufacturers 
may also be attractive 
to some 
network 
developers 
as may 
special 
purpose, 
one-of-a- 


kind, 
protocols. 


The Xerox 
protocols 
were chosen 
because 
they could be 
used 
to demonstrate 
a multivendor 
interconnect 
using 


Ethernet. 
They also were chosen since they were based on 


an operational 
system 
which 
reduced 
the risk of logic 


flaws. 
Further, 
the protocols 
were conceptually 
easy to 


understand 
and structured 
into layers. 
Finally, 
only por- 


tions of the protocol 
needed to be implemented 
to demon- 


strate 
a multi vendor 
file transfer 
facility. 


We chose 
to implement 
a file transfer 
facility 
and 
a 


primitive 
file server on the System 86/330. 
The file trans- 


fer facility was implemented 
as a non-resident 
command 


of the iRMX 86 Operating 
System. The command 
offered 


a user interface 
similar to the standard 
Human 
Interface 


COpy 
command. 
The file transfer 
command 
was very 


easy to implement 
since the iRMX 86 Human 
Interface 
of- 


fers standard 
system calls for most of the features 
needed. 


l;he 
file server 
was implemented 
as a permanent 
task 


which could 
OPEN, 
CLOSE, 
READ 
or WRITE 
a file. 


The file server protocol 
was implemented 
from the exam- 


ple in the Xerox 
Courier 
publication 
[6)since 
the 
file 


server protocol 
was not available 
from Xerox at the time 


of implementation. 
The file server 
can process 
requests 


from multiple 
file transfer 
commands. 


The file server was implemented 
as a very simple interface 


to the iRMX 
86 Operating 
System 
named 
file structure. 


No tables were required to remember 
information 
between 


requests 
since all file environment 
information 
was main- 


tained by either the iRXM 86 Operating 
System or the File 


Transfer 
Command 
Task. 


The Courier[6) 
and Sequenced 
Packet 112)protocols 
were 


the most difficult 
to implement 
and debug 
but each was 


simple 
to understand. 
The main 
problem 
was correctly 


managing 
the numerous 
error paths but this is very typical 


of data 
communications 
protocols. 
The Internet 
proto- 


col1l21was implemented 
as a separate 
set of tasks without 


attempting 
to support 
the multiple 
network 
case. Thus, 


it was little more than a pass-through 
procedure 
to inter- 


face with the Ethernet 
driver 
provided 
by the iRMX 
86 


Operating 
System. 


Each layer of the Xerox 
protocol 
corresponds 
to a layer 


of the ISO Model!!'! 
Note that the session layer is not re- 


quired 
nor provided 
in the Xerox architecture 
(see Figure 


8-1). Each layer of protocol 
was implemented 
as a separate 


set of tasks, 
each communicating 
with the adjacent 
layer 


via operating 
system message 
exchanges. 
In some cases, 


the layers were implemented 
as several dependent 
tasks to 


ease the problem 
of processing 
unsolicited 
requests 
for 


service 
from both 
adjacent 
layers. 
It also allows the ex- 


istence of alternate 
implementations 
of an adjacent 
layer 


protocol, 
but this feature 
was not explored. 


The code consisted 
of 4000 lines of PLM statements 
and 
occupied 
12K bytes of memory 
(see Figure 
8-2). Addi- 


tional 
memory 
was needed to support 
data buffering 
and 
various 
system table structures. 
The dynamic 
memory 
re- 
quirements 
were about 
10K in our example. 
The memory 


requirement 
for both code and buffering 
can be reduced 


by using the compilers 
optimization 
options 
and through 


careful 
memory 
resource 
management. 


iRMX'· 86 
OPERATING 
SYSTEM 


Module 
Lines 
Memory 


of Code 
(code only) 


1. Internet Protocol Tasks 
675 
1.8K 


2. Sequence Packet Tasks 
690 
2.8K 


3. Courier Tasks 
1100 
4.0K 


4. File Server Task 
570 
1.4K 


5. File Transfer Command 
760 
1.9K 


3375 
11.9K 


Figure 8-2. Application 
Memory Requirements 


This code represents about 2 months of work to study, im- 
plement and unit test. However, the development of this 
code as a standard product with adequate documentation 
and system test would require additional work. Using 
equations available in the Mythical Man Month III this 
code would require 12 months effort. The inclusion of 
enhanced features of the network could easilyincrease this 
implementation multifold. These enhanced features would 


include network statistics, network gateways, internet 
datagrams, etc. 


The Ethernet Application was very easy to debug due to 
the iRMX debug monitor offered by System 86/330. A 
moderate speed printer was essential to this task since hard 
copy listings and memory maps were necessary. The 
system performed very well as a development station, 
partly due to the high performance of the Winchester 
Disk. 


The developers of applications for Ethernet can choose 
one of two ways to implement higher levelcode. First, the 
Model 675 Development Station for Ethernet can be 
chosen which brings an Ethernet controller and all the 
development tools available to microprocessor develop- 
ment. (One can also add the Model 667 DS/E upgrade to 
an existing Intellec Series II or III.) This option allows the 
use of In-Circuit Emulators and the support of EPROM 
programmers. A second choice is the iSBC 550 Ethernet 
Controller which is added to a MULTIBUS system. The 
latter was chosen for this Application Note sincethe System 


inter 


86/330 
provided sufficient development capabilities for 


this task. 


The source code for this application may be obtained from 
the Insite Program Library. The program title is "Xerox 
File Transfer Facility:' Listings are not included in this 
Application Note due to the large number of pages re- 
quired. 


The iSBC 550 Ethernet Controller is a fully functional 
local area network controller which exceeds the require- 
ments for a prototype development tool. Its performance 
permits its use in a variety of application environments, 
particularly where early introduction of Ethernet-based' 
products is desired. Intel's commitment to Ethernet VLSI 


components makes future products very attractive, and 
the iSBC 550 Ethernet Controller will offer OEM manu- 
facturers a lead-in product for future Intel support of local 
area networks. 


The performance of the iSBC 550Ethernet Controller and 
its ease of integration into MULTIBUS systems ensures 
its successin office environments. In factory environments, 
the controller willbe equally successful, particularly when 
conduit shielding is used. 


Future products from Intel will offer increasing perform- 
ance for less cost both from the availability of VLSI com- 
ponents and new board level products supporting the 
VLSI component. Increasing levels of integration will be 
possible, including standard software support for Ethernet 
Interfaces both for Intellec Development Systems and 
iRMX 86 Operating Systems. 
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APPENDIX A 
LAB TEST RESULTS 


inter 


iSBC® 550 ETHERNET* 
CONTROLLER 
iSaC® 550 ETHERNET* CONTROLLER 


Standard 
Software 
Test Results 
Custom Software 
Test Results 


The standard 
software 
test results were obtained 
with the 
The custom 
driver 
results 
were obtained 
by substituting 
system configuration 
as defined 
in Section 6. The follow- 
the standard 
iRMX 86 driver with a stand-alone 
driver as 


ing application 
parameters 
are appropriate: 
discussed 
in Section 
6. The application 
parameters 
are 


block 
size 
the size of the user data 
con- 
identical 
for these cases as for the standard 
software. 
Case 


tained 
in an Ethernet 
block 
V differs 
from all other cases since it does not impose 
an 


block 
the actual 
count 
of blocks 
which 
end-to-end 
protocol. 
It simply presents 
data to the iSBC 


made the round 
trip in the sam- 
550 controller 
as fast as it will transmit 
the data. 


pie interval 
of 10 seconds 


input 
and output 
the effective 
bit rate of user data 


in each direction 
I. ONE OUTPUT 
BLOCK 
IN QUEUE 
average 
response 
the total time interval 
divided 
by 


Average 
Maximum 
time 
the number 
of blocks 


Block 
Input 
Output 
Response 
Response 


maximum 
response 
worst case time for a block to 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 
time 
make one round 
trip (10 msec 
(Bytes) 
Blocks 
sec) 
sec) 
(msec) 
(msec) 
clock resolution) 


number 
of blocks 
the number 
of blocks 
which 
100 
673 
54 
53 
14 
20 


in queue 
could 
be transmitted 
but not yet 
200 
611 
97 
97 
16 
20 
acknowledged 
500 
476 
191 
190 
21 
30 


1000 
349 
279 
279 
28 
30 


I. TWO BLOCKS 
IN QUEUE 
1500 
276 
337 
330 
36 
40 


Average 
Maximum 
Block 
Input 
Output 
Response 
Response 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 
II. 
TWO OUTPUT 
BLOCKS 
IN QUEUE 


(Bytes) 
Blocks 
sec) 
sec) 
(msec) 
(msec) 
Average 
Maximum 


100 
107 
8 
8 
93 
260 
Block 
Input 
Output 
Response 
Response 


200 
108 
17 
17 
93 
250 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 


(Bytes) 
Blocks 
sec) 
~ 
(msec) 
(msec) 


500 
103 
41 
40 
98 
240 


1000 
101 
80 
80 
100 
260 
100 
792 
64 
63 
12 
30 


1500 
103 
121 
121 
98 
280 
200 
702 
112 
112 
14 
30 


500 
585 
233 
234 
17 
40 


1000 
572 
458 
457 
17 
40 


II. 
ONE BLOCK 
IN QUEUE 
1500 
451 
546 
546 
22 
50 


Average 
Maximum 
Block 
Input 
Output 
Response 
Response 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 


(Bytes) 
Blocks 
sec) 
see) 
(msec) 
(msec) 
III. 
THREE OUTPUT 
BLOCKS 
IN QUEUE 


1000 
88 
70 
69 
115 
150 
Average 
Maximum 


Block 
Input 
Output 
Response 
Response 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 


III. 
FOUR BLOCKS 
IN QUEUE 
(Bytes) 
Blocks 
sec) 
sec) 
(msec) 
(msec) 


Average 
Maximum 
100 
941 
75 
74 
II 
40 


Block 
Input 
Output 
Response 
Response 
200 
870 
140 
140 
11 
40 


Size 
(Kbits/ 
(Kbits/ 
Time 
Time 
500 
733 
292 
293 
13 
50 
(Bytes) 
Blocks 
sec) 
sec) 
(msec) 
(msec) 
1000 
574 
459 
459 
17 
60 


1000 
101 
80 
80 
100 
470 
1500 
436 
523 
522 
23 
70 


8-139 
AFN-Q1332A 


IV. 
FOUR OUTPUT 
BLOCKS 
IN QUEUE 
Time-out 
If a block is discarded due to a CRC 


Average 
Maximum 
error or error collision, the data must be 
retransmitted by higher additional layers 
Block 
Input 
Output 
Response 
Response 
of protocol. In this case, a timer expires 
Size 
(Kbits/ 
(Kbits/ 
Time 
Time 
when a response is not received and the 
(Bytes) Blocks 
see) 
~ 
(msec) 
(msec) 
original block is repeated 


100 
847 
71 
71 
II 
50 


1000 
572 
458 
457 
17 
80 


V. 
TWO BLOCKS 
IN QUEUE (OUTPUT 
ONLY) 


Average 
Maximum 


Block 
Input 
Output 
Response 
Response 


Size 
(Kbits/ 
(Kbits/ 
Time 
Time 


(Bytes) Blocks 
see) 
see) 
(msec) 
(msec) 


100 
191 
0 
153 


200 
181 
0 
289 


500 
161 
0 
644 


1000 
125 
0 
1008 


1500 
103 
0 
1236 


The noise immunity tests are based on the custom software 
tests. The tests were all run with a block size of 1000bytes 
and two blocks in the queue. The environment for these 
tests is described in Section 7. 


The following definitions apply to these measurements: 
Primary 
An attempt to transmit a block was pre- 


Collision 
maturely ended due to the collision detec- 
tion logic reporting an error. These ap- 
pear to all be due to noise rather than by 
simultaneous access of two stations 


A secondary collision is reported if a 
block experiences a collision upon its sec- 
ond or subsequent retry following a pri- 
mary collision 


Secondary 
Collision 


Error 
Collision 


An error collision is reported if 16 
attempts to transport a single block are 
all terminated by a collision 


A receiving station will verify the CRC of 
each incoming block. If incorrect the 
block is discarded and the error count 
incremented 


Framing 
Error 
A block of more than 1500 bytes is dis- 
carded as a framing error 


I. COAXIAL 
CABLE 
NOISE IMMUNITY 


(2 hours 
50 minutes) 


Primary Collisions 
Secondary Collisions 
Error Collisions 
CRC Errors 
Framing Errors 
Time-out 


II. 
TRANSCEIVERITRANSCEIVER 
CABLE 
NOISE 
IMMUNITY 
(2 hours 
54 minutes) 


Primary Collisions 
Secondary Collisions 
Error Collisions 
CRC Errors 
Framing Errors 
Time-out 


III. 
IMMUNITY 
IN VICINITY 
OF ARC WELDER, 


200 AMP-DC 
(5 minutes) 


Primary Collisions 
Secondary Collisions 
Error Collisions 
CRC Errors 
Framing Errors 
Time-out 


IV. 
IMMUNITY 
IN VICINITY 
OF ARC WELDER, 


180 AMP-AC 
(5 minutes) 


Primary Collisions 
Secondary Collisions 
Error Collisions 
CRC Errors 
Framing Errors 
Time-out 


inter 


VI. 
CASE II REPEATED 
IN DEVELOPMENT 
LABORATORY 
(13 hours 
30 minutes) 


Primary Collisions 
0 


Secondary Collisions 
0 


Error Collisions 
0 


CRC Errors 
0 


Framing Errors 
0 


Time-out 
0 


V. 
IMMUNITY 
IN VICINITY 
OF ARC WELDER, 
NOT WELDING 
(5 minutes) 


Primary Collisions 
Secondary Collisions 
Error Collisions 
CRC Errors 
Framing Errors 
Time-out 
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APPENDIX B 


SOFTWARE PERFORMANCE RESULTS 


Standard iRMX 86 Operating System and iMMX 800 
MULTIBUS Exchange 
Custom 86/330 driver developed for this application 
Custom iRMX 86 Operating System Ethernet data 
link interface 


Time to Output One Block 
from User Application 


42.5 milliseconds 


Dual-port RAM hikes throughput 
in inpuVoutput controller board 


On-board random-access memory, accessible from system bus, 
makes input! output controller subsystem look like 


just another memory board to the host micropr0cessor 


o Input/output 
controllers based on microprocessors 
step up throughput in microcomputer systems by reliev- 
ing the host processor of tedious, time-consuming control 
tasks-and 
a new design concept that 
increases the 
processing capability of this subsystem promises to hike 
throughput even more. It will cut the host intervention 
needed to transfer data and to run the controller. 
In this configuration, all communications between the 


host processor and the controller are handled through a 
section of dual-port memory that resides in the controller 
subsystem. This setup allows more efficient transfer of 
large blocks of data from the 110 device to the system 
without contention over access to the system bus. It also 


simplifies interprocessor 
communications 
because the 


subsystem controller appears to the host processor sim- 
ply as an additional RAM board. 


Although this concept allows the subsystem to remain 


dedicated to its 110 control function and to assume a 
subservient 
role to the host processor, it has more 


processing power than previous generations 
of such 


controllers. Hence it has been dubbed the intelligent- 
slave concept by Intel, which applies it in the iSBC 544 
intelligent communications controller. 


The new subsystem architecture is divided into three 


major sections: dedicated 
1/0, dedicated computer, and 


dual-port memory (Fig. I). The dedicated input/output, 


1. Heert of memory. 
New controller archi- 


tecture includes the dedicated inputl output 
circuitry and dedicated processor 01an intel- 
ligent peripheral controller, 
but its heart is 


the dual-port random-access memory. 
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2. Perform.nee 8dY.nlllll", 
In adding a real-time task to an existing real-time system, the load on the system bus Is significantly reduced 


over the traditional multitasking approach (a) or the Intelligent controller approach (b) by the intelligent-slave controller approach (c). 
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3. The 544. Based on the SOS5A microprocessor with 4 kilobytes of PROM and 16 kilobytes of RAM, the subsystem is designed as a 
communications controller with four synchronous/asynchronous 
buffered serial I/O channels, and a la-bit parallel I/O interface. 


The concept of a dual-port read-write memory used in the 
iSBC-544 
communications 
board 
is also 
employed 
in 
another new Intel product: its latest single-board 
comput- 
er, the 
iSBC-80/30. 
A dual 
port 
makes 
the 
80/30's 


random-access 
memory" directly accessible 
by the on- 
board 8085A central 
processing 
unit via internal busing 
without tying up the external system bus, the Multibus. At 
the same time, it also maKes the RAM directly accessible 
by any other boards, 
like direct-memory-access 
control- 
lers or other one-board 
computers 
that may be tied to the 
Multibus. 


Moreover, 
the 
80/30 
adds 
its dual-port 
bus to the 
earlier iSBC computers' 
pair of buses: 
an internal 
bus, 
which hooks the CPU to peripheral chips and read-only- 
memory program storage and the system bus, over which 
the CPU and other boards communicated 
with RAM. Eight 
bits wide, the new bus is connected 
to a pair of buffer 


registers that coordinate, 
thus making the RAMaccessible 
either by the internal bus or the system bus. 
The objective 
is throughput: 
the CPU has priority in 


access 
to the on-board 
RAM. But since the access 
is not 
over the Multibus system 
bus, which might be tied up, 
there is no waiting. From the viewpoint of other system 
boards, the system bus is accessible 
a greater percentage 


of the time. 


With the incorporation of 16 kiloby1es of memory on the 


80/30, 
Intel had little choice but to move to the dual-port, 


triple-bus 
architecture. 
The reason 
is that 
few system 


designs require more than 16 kilobytes, so in many appli- 
cations 
all boards 
will be 
demanding 
access 
to 
the 
80/30's 
memory over the Multibus. The CPU had better 
have priority to its RAM, through its own private line, .Iest 
the queue for the system bus bog down throughput. 


The 80/30 
also packs lots of extras, in addition to the 


total 16,384 by1es of read/write 
memory built with 2116 


16-K dynamic 
RAMs. A pair of ROM sockets 
provide 
4,096 by1es of program storage iffitted with 16-K erasable 
programmable 
read-only 
memories 
like the 2716. When 


pin-compatible 
32-K 
erasable 
PROMs 
are 
available, 


program storage can be extended 
to 8 kiloby1es. 
Also on board is a socket for Intel's universal peripheral 
interface 
chip, 
the 
8041 
(or 
8741 
erasable-PROM 
version), which can function as a slave processor 
to drive 
peripheral 
devices. 
An 
8251A 
universal 
synchro- 


nous/asynchronous 
receiver/transmitter 
is included 
for 


serial communications, 
and the 80/30 
also boasts 
three 


16-bil 
programmable 
timers. 
The 
24 
programmable 
input! output lines are brought out to sockets 
that accept 


quad line-drivers or -terminators for interfacing. 
R.ye.pece 


conslsllng 
of 
the 
necessary 
peripheral 
chips, 
timers, 
buffers, 
and 
interface 
integrated 
circuits, 
tailors 
the 


controller 
to the application's 
110 requirements. 
The dedicated 
computer 
consists 
of a general-purpose 


microprocessor, 
electrically 
programmable 
read-only 


memory, 
dedicated 
RAM, timers, 
interrupt 
logic, and the 
decode 
and chip-select 
logic. The size and speed of the 


central-processing 
unit 
can 
be 
tailored 
to 
match 
the 


requirements 
of the dedicated 
110 section. 
The dual-port 
memory 
is the heart 
of the architecture 


and sets it apart 
from traditional 
approaches 
to intelli- 


gent 
controllers 
and 
multiprocessing. 
Passing 
all 


commands 
and data between 
the system and the control- 


ler's 
processor 
through 
this memory 
offers a number 
of 


significant 
advantages. 
First, 
the 
dedicated 
computer's 
performance 
can 
be 


optimized 
for its applications. 
Its software 
always 
oper- 


ates 
at 
full speed, 
since 
all required 
memory 
and 
110 


resources 
are immediately 
accessible 
on the board, 
with- 


out indeterminate 
delays caused 
by other system activity 


on the bus. This accessibility 
is especially 
important 
in 


real-time 
systems, 
since 
it 
allows 
the 
controller's 


performance 
to remain 
constant 
even though 
system 
bus 


activity 
may change. 


Secondly, 
the 
architecture 
presents 
a consistent 
and 


convenient 
interface 
between 
the 
host 
CPU and 
all the 


controllers 
in the system, 
regardless 
of function. 
Because 


the controllers' 
dual-port 
RAM looks to the host CPU like 


just 
another 
location 
in system 
memory, 
the 
hardware 


and software 
problems 
associated 
with connecting 
multi- 


ple 
processors 
together 
are 
reduced 
to 
interfacing 
a 


number 
of identical 
intelligent 
memory 
locations. 
Also, the architecture 
offers a degree of protection 
for 


the data 
in memory. 
The subsystem 
computer 
and soft- 


ware can only alter 
that 
portion 
of system 
memory 
that 
resides in its own dual-port 
memory 
section. 
In contrast, 


traditional 
intelligent 
controllers 
have 
access 
to 
the 
entire 
system 
RAM and, should 
a malfunction 
occur, 
can 
destroy 
all of that memory. 


System performance 
advantages 


Because 
all processing 
assigned 
to the new controller's 
CPU takes place off the system 
bus, its architecture 
offers 
important 
performance 
advantages 
to the system. 
These 
advantages 
come 
from the appearance 
of the processed 
data 
blocks 
in system 
memory 
without 
consuming 
any 


system resources 
or bus time 
The 
advantages 
of 
this 
approach 
are 
best 
demon- 
strated 
by comparing 
it to alternative 
means 
of adding 
a 
real-time 
task 
to an existing 
real-time 
system. 
In this 
case, the new task requires 
additional 
cPu, memory, 
and 
I/O resources. 


The 
traditional 
multiprocessor 
approach 
of 
Fig. 
2a 
expands 
CPU 
resources 
in one 
of two 
ways: 
software 
utilization 
of reserve 
capacity 
in the existing 
processor, 
or adding 
another 
processor. 
In either 
case, memory 
and 


110 increments 
generally 
will be required. 


The 
primary 
disadvantages 
of this approach 
are 
the 
increased 
complexity 
of the 
system 
software 
and 
the 
increased 
load 
on the 
system 
bus. 
Both 
will slow 
the 
existing 
real-time 
system 
unless 
it has 
been 
designed 
with adequate 
reserve. 
The system 
bus must also provide 
sufficient 
capacity 
for the 
incremental 
memory-execu- 


tion 
and 
data-transfer 
operations. 
This 
additional 
bus 


load will also require 
that the primary 
real-time 
task can 


tolerate 
CPU delays due to bus contention. 


The 
intelligent-controller 
approach 
of 
Fig. 
2b 
has 


gained 
widespread 
use since the advent 
of the micropro- 


HEXADECIMAL 
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{ 


4. IIemorJ 
IIUIPPInlI- The variable system memory addresses are 
always mapped Into the on-board address of 8OOOHEX.providing 
software independence for the subsystem and the host. 


cessor. This approach combines the CPUand 1/0 incre- 
ments onto a single module that usually includes direct- 
memory-access transfer logic. In some cases the execu- 
tion memory for the CPUis included. 


This approach lessens the bus-loading problem since 
the 1/0data transfers and some memory-execution cycles 
take place off the system bus. However, both cpus' 
programs 
will have 
to tolerate 
delays 
caused 
by 
increased bus contention. Increased software sophistica- 
tion is the primary disadvantage of this approach, much 
as with the multiprocessing approach of Fig. 2a. 


The intelligent-slave 
approach 
of Fig. 2c can 
be 
viewed as a logical extension to the intelligent-controller 
approach. Combining the CPU.1/0, and memory incre- 
ments creates a single module that has a minimal impact 
on the existing system software and bus loading. What's 
more, the subsystem can operate at full capacity without 
regard to other system activity. It can be programmed 
outside the primary system and then added with minimal 
impact on the system software or performance. 
A limitation of the approach is the inability of the 
subsystem to transfer data into portions of the system 
memory space that reside off its board. This problem is 
minimized by the ability of the controller's RAMto serve 
as a substantial 
portion of the entire memory space 
addressable by the system. In this light, the on-board 
processor can be viewed as having a DMAcapability 
limited to a portion of the system's address space. 


In a system with more than one of the new controllers, 
the system CPUhandles any data that must be trans- 


ferred from one to another. Applications involving the 
transfer of large blocks of data would be best served by a 
central block-transfer device elsewhere on the bus. 
'The 
advantages offered by the new approach in this 


example of adding onto an existing system are just as 
applicable 
to 
a 
ground-up 
design. 
This 
modular 


approach 
to configuring 
real-time 
multiprocessing 


systems simplifies hardware and software design, as well 
as system integration. 


While the primary design objective of the new archi- 


tecture is operation in a multiprocessing system, it can 
provide significant utility 
as stand-alone 
processors. 


Thus these controllers incorporate a second mode of 
operation called the limited bus-master mode. 


In this mode of operation the new controller can be 


used like a single-board computer as long as it is the 
system's only master of the bus, It can be connected to 
standard memory or 1/0 expansion boards to enhance its 
capability. 
It can even be used to drive other such 


controllers as long as they are used in the subsystem 
mode. This dual operational mode will allow the new 
controllers to serve a broad range of applications. 


Communic8llona firal 


Communications 
applications 
present complex pro- . 


cessing requirements and an inherent real-time nature, 
so it is logical that a communications processor be the 
first of these new controllers to be marketed. The iSBC 
544 intelligent communications controller can serve as a 
flexible front end to an iSBC system or as a cost- 
effective stand-alone processor configured as a terminal 
cluster or line concentrator. Its design (Fig. 3) incorpo- 
rates an 8085A cPu, 16 kilobytes of dual-ported dynamic 
RAM, 4 kilobytes of PROM, programmable 
interrupt 


control, three interval timers, four programmable baud- 
rate 
generators, 
four synchronous/asynchronous 
buf- 


fered serial 1/0 channels, and a lo-bit parallel interface 
compatible with a Bell 801 automatic calling unit. 


The dual-port memory block basically consists of the 


16-kilobyte bank of random-access memory, which is 
accessible from either the system bus or the on-board 
processor through the dual-port controller. This memory 
block provides the primary means of communication 
between the system and the on-board 8085A. The port to 
the memory, which looks to the system bus like any other 
RAMcard belonging to the system, features full 2o-bit 


i:lUUl~~1I1~ 
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The interface's address-decode logic allows switching 


of the base address of the iSBC 544 to any 4-kilobyte 
boundary in the host system's address space. In addition, 
the user may reserve 8, 12, or 16 kilobits of the 544's 
memory for use by the on-board processor only. This 
reserved memory is not accessible from the system bus 
and does not occupy any system address space. The only 
restriction is that all of the unreserved memory reside in 
the same 64-Kaddress page of the system memory. 
This memory division' can be a significant advantage 


in large 8-bit microcomputer systems. Only that portion 
of the controllers' memory needed to pass data between 
cpus 
must be made 
accessible to the system. The 


remaining 
buffer 
and 
execution 
memory 
does 
not 


consume any system address space. 
The net result is an increase in the system's overall 


memory capacity. For example, a microcomputer system 
that would usually be limited to 64 kilobytes of memory 
has a total memory capacity of over 190 kilobytes when 
driving seven 544s. 


Addr ••• 
mapa and interrupt. 


To the on-board processor, the base address of its 
memory is fixed at 8000HEX.Furthermore, all on-board 
addresses are fixed, so that multiple 544s operating on 
the same system bus can be running identical programs 
regardless of their base address on that bus. This capa- 
bility necessitated the address-mapping logic to trans- 
form addresses from the system bus into the equivalent 
in the 
on-board 
address 
space starting 
at 
location 


8000HEX(Fig. 4). 
The address-mapping logic also implements the f1ag- 
interrupt 
feature. It provides an interrupt 
to the on- 
board processor whenever a byte is written into the 544's 
base address from the system bus, and a read from the 
on-board processor to the base address clears the inter- 
rupt. Since each 544 in a system has a different base 
address in that system's 
RAM, 
it also has a unique 
interrupt. This flag-interrupt capability is a key element 
in establishing a protocol for communications between 
the host CPU and the subsystems' processors. 
The dual-port control logic is responsible for resolving 


contention over access to the memory and is designed to 
optimize the performance of the subsystem CPU. Unless 
the system bus has initiated a memory cycle before the 
on-board processor requests memory, that 
CPU runs at 


full speed. The maximum delay that can be encountered 
is one memory cycle. The arbitration 
logic actually 


reserves the memory for the on-board processor before it 
generates the necessary commands. This advance reserv- 
ing guarantees that the on-board CPU will suffer mini- 
mum intervention from system bus accesses. 
When the iSBC 544 is used in the stand-alone limited 


bus-master mode, the dual-port logic is disabled and the 
bus interface buffers are turned around to drive onto the 
bus. This reversal allows the on-board central-processing 
unit access to the memory of other subsystems or 
110 


expansion boards on the system bus. 
The dedicated computer is built with an 8085A CPU 
operating at 2.76 megahertz, between 2 and 4 kilobytes 
of PROM and ROMS or 8 kilobytes of ROM using 2332 


5. Communic:tltlona 
applic:tltlona. 
Two typical applications of the 


new iSSC 544 would be as a front-end communications processor to 
a microcomputer system and as a remote concentrator to a series of 
point-ta-point or multidrop connected terminals. 


mask-programmable parts, 256 bytes of static RAM, two 
16-bit and one 
14-bit interval 
timers, 
and 
a 8259 


programmable interrupt controller for individual receive 
or transmit interrupt inputs for each serial port. 


Special command-decode logic was added to the CPU 


to allow it to operate at maximum speed independent of 
other system activity. There are 21 sources of interrupt 
on the 544, including the separate transmit and receive 
interrupts for each port and separate timer interrupts. In 
addition to receiving an interrupt from the system, the 
544 can also send an interrupt to the system bus via the 
8085A's serial-output data line. 


Since this controller is intended for communications 


applications, latched interrupts are provided directly to 
the CPU for loss of carrier and ring indicator for all four 


110 ports. The ring-indicator and carrier-detect lines car 
also be monitored through the parallel port. 


Dedicated I/O 


The dedicated-I/o section of the 544 provides a high 


degree of flexibility and programmability. 
This results 


primarily from the inclusion of four 8251A universal 
synchronous/asynchronous 
receiver/transmitters. 
These 


devices are programmable for synchronous or asynchro- 
nous mode, character 
size, parity bits, stop bits, and 


baud rates. Data, clocks, and control lines are buffered 
with RS-232-C~ompatibJe 
drivers and receivers to four 


26-pin card-edge connectors. Each port is configured as 
a data-terminal 
interface, but may be converted to a 


iSlIC !l44 
, 
. 
INTEL(!G.flWT 
PEIIIPltERAL 
COIITRblLER 
PERFORMlfCG; 
a DIll'A-UIIK 
COIITROL 
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a CODE CONVERSION 


e. From aleva to maatar. In its stand-alone mode, the 544 can operate as a bus master and be configured as an intelligent terminai controller 
connecting dumb terminals to a data link (a) or as a peripheral controller connecting RS-232-G-compatible units to the terminal (b). 


data-set 
interface 
by changing a single jumper-plug 
assembly. The ports support most RS-232-C 
signals 
(those that are listed in the table). 
A programmable baud-rate generator is also provided 
for each port. The range of baud rates available is 75 te 
56 kilobits per second. The generators are implemented 
with 8253 programmable interval timers, which receive a 
jumper-selectable input frequency of 1.84 or 1.23 MHZ. 
In addition, one of the cpu's 
interval timers can be 
converted to baud-rate operation and jumpered to any 
port to provide it with split-speed operation. 
The 
544 also provides a parallel 
port with four 
RS-232-C 
buffered 
input 
lines and 
six 
RS-232-C 
buffered output lines. This port is configured to interface 
to most automatic calling units but may be used as a 
general-purpose I/O port. It is implemented with an 8155 
programmable peripheral interface that also provides the 
256 bytes of static RAM and the 14-bit timer. 


Applications 


A likely common use of the 544 as a subsystem is as a 
front-end processor or (erminal multiplexer (Fig. 5) in 
an iSBC system. The 544 performs all communications- 
related functions such as format control, code conver- 
sion, data-link control, error checking, data compression, 
and protocol management. It can handle multiple proto- 
cols, line speeds, and data formats. 
All the system processor sees are the processed data 


blocks that appear in system memory. An automatic 
dialer could be added to provide a dial-up connection to 
a host processor or network. 
Also shown in Fig. 5 is another 544 used in its limited 
bus-master mode as a remote concentrator and terminal 
controller. The line and memory capacity of the remote 
concentrator can be increased by the addition of stan- 
dard iSBC memory and I/O expansion boards. 
The intelligent-terminal controller shown in Fig. 6a is 
a prime example of a 544 used in the stand-alone mode. 
It can connect one or more dumb terminals to a data link 
and provide the necessary buffering, code conversion, 
and data-link control. It could also connect a terminal 
that happens to communicate in a different protocol to a 
new network or to more than one network. 
The iSBC 544's multiple serial lines do not have to be 
used for communications. They can also be used to 
connect RS-232-C-<:ompatible peripherals to the termi- 
nal (Fig. 6b). In this configuration, the 544 can provide 
message editing and formatting, bulk storage, and hard- 
copy output. 


As this last application 
suggests, the 
544 is the 
vanguard of a family of intelligent I/O controllers that 
will add tremendous increases in throughput and versa- 
tility to the iSBC line of single-board computers. The 
basic architecture will simplify the task of developing 
multiprocessing hardware and software solutions that 
will overcome throughput limitations. 
D 


and Signal Conditioning 
Boards 


iSBC 569 
INTElliGENT 
DIGITAL CONTROllER 


• Single board digital 110controller with 
up to four microprocessors to share the 
digital input/output signal processing 


• 3 MHz 8085A central control processor 


• Three sockets for 8041/8741A Universal 
Peripheral Interface (UPI-41A) for dis- 
tributed digital I/O processing, such as: 


- 
Industrial signal processor 
(ISBC 941) 
- 
Custom prograrpmed 8041A18741A 


• Three operational modes 


- 
Stand-along digital controller 
- 
MULTIBUS master 
- 
Intelligent slave (slave to 
MULTIBUS master) 


• 2K bytes of dual port static read/write 
memory 


• Sockets for up to 8K bytes of Intel 2758, 
2716, 2732 erasable programmable read 
only memory 


• 48 programmable parallel I/O lines with 
sockets for interchangeable 
line drivers 
or terminators 


• Three programmable counters 


• 12 levels of programmable interrupt 
control 


• Single + 5V supply 


• MULTIBUS standard control logic 
compatible with optional iSBC 80 and 
iSBC 86 CPU, memory, and I/O 
expansion boards 


The 
Intel 
iSSC 
569 
Intelligent 
Digital 
Controller 
is a single 
board 
computer 
(8085A 
based) 
with 
sockets 
for three 
8041A/8741A 
Universal 
Peripheral 
Interface 
chips (UPI-41A). 
The I/O processing 
algorithm 
may be tailored 
to application 
requirements 
using designer 
selected 
combinations 
of standard 
Intel industrial 
signal processors 
(e.g., iSSC 941) or user 
programmed 
UPI-41A 
processors. 
These devices may be used to offload 
the 8085A processor 
from time consuming 
tasks 
such 
as pulse 
counting, 
event 
sensing, 
and 
parallel 
or 
serial 
digital 
I/O 
data 
formatting 
with 
error 
checking 
and 
handshaking. 
The iSSC 569 board is a complete 
digital 
controller 
with up to four processors 
on a single 6.75 inches x 12.00 
inches 
(17.15cm 
x 30.48cm) 
printed 
circuit 
board. 
The 8085A 
CPU, 
system 
clock, 
read/write 
memory, 
non-volatile 
memory, 
priority 
interrupt 
logic, 
programmable 
timers, 
MUL TISUS 
control 
and interface 
logic, 
optional 
UPI processors 
and optional 
line driver 
and terminators 
all reside on one board. 


FUNCTIONAL 
DESCRIPTION 


Intelligent Digital Controller 


Three modes of operation - 
the 
iSSC 
569 Intelligent 
Digital 
Controller 
is capable 
of operating 
in one of three 


modes: stand alone controller, 
bus master, or intelligent 


slave. 


Stand alone controller 
- 
the 
iSSC 
569 
board 
may 
function 
as a stand 
alone, 
single 
board controller 
with 


CPU, memory, 
and I/O elements 
on a single 
board. 
Five 


volt (+5VDC) 
only operation 
allows 
configuration 
of low 


cost 
controllers 
with 
only 
a single 
power 
supply 


voltage. 
The on-board 
2K bytes RAM and up to 16K bytes 
ROM/EPROM, 
as well as the assistance 
of three UPI-41A 


processors, 
allow 
significant 
digital 
I/O control 
from 
a 


single 
board. 


Bus master - 
in this 
mode of operation, 
the iSSC 569 


controller 
may interface 
with and control 
iSSC expansion 
memory 
and 
I/O 
boards, 
or 
even 
other 
iSSC 
569 
Intelligent 
Digital 
Controllers 
configured 
as intelligent 


slaves (but no additional 
bus masters). 


Intelligent slave - 
the iSSC 569 controller 
can perform 
as 


an intelligent 
slave to any 8- or 16-bit MUL TISUS master 


CPU by ollioading 
the master of digital 
control 
related 


tasks. 
Preprocessing 
of data for the master is controlled 


by the on-board 
8085A CPU which coordinates 
up to three 


UPI-41A 
processors. 
Using 
the 
iSSC 
569 board 
as an 


intelligent 
slave, 
multi-channel 
digital 
control 
can 
be 


managed 
entirely 
on-board, 
freeing 
a system 
master to 


perform 
other 
system 
functions. 
The 
dual 
port 
RAM 


memory 
allows 
the iSSC 
569 controller 
to process 
and 


store data without 
MUL TISUS 
memory 
contention. 


Simplified Programming 


Sy using Intel UPI-41A processors 
for common 
tasks such 


as counting, 
sensing 
change of state, printer 
control 
and 


keyboard 
scanning/debouncing, 
the user frees up time to 


work on the more important 
application 
programming 
of 
machine 
or process 
optimization. 
Controlling 
the 
Intel 
UPI-41A 
processors 
becomes 
a simple task of reading or 


writing 
command 
and data bytes to or from the data bus 
buller 
register 
on the UPI device. 
Programming 
the iSSC 
941 Industrial 
Digital Processor to produce 
a pulse output, 


for 
example, 
is as simple 
as sending 
command 
and 
parameter 
bytes 
indicating 
initialization, 
pulse 
output 
selection, 
period 
and 
delay 
parameters, 
followed 
by a 


command 
to begin execution. 


Central Processing Unit 


A powerful 
Intel 8085A 8-blt 
CPU, fabricated 
on a single 


LSI chip, 
is the central 
processor 
for the iSSC 
569 
™ 


controller. 
The six general 
purpose 
8-bit 
registers 
may 


be addressed 
individually 
or 
in pairs, 
providing 
both 
single 
and 
double 
precision 
operations. 
The 
program 
counter 
can address 
up to 64K bytes of memory 
using 
iSSC 
expansion 
boards. 
The 
16-bit 
stack 
pointer 
controls 
the addressing 
of an external 
stack. 
This stack 
provides 
sub-routine 
nesting 
bounded 
only 
by memory 


size. The 
minimum 
instruction 
execution 
time 
is 1.30 
microseconds. 
The 8085A 
CPU is software 
compatible 


with the Intel 8080A CPU. 


Bus Structure 


The iSSG 569 Intelligent 
Digital Controller 
utilizes a triple 


bus architecture 
concept. 
An Internal 
bus is used for on- 
board 
memory 
and 
I/O 
operations. 
A MULTISUS 


interface 
is available 
to provide 
access 
for all external 
memory 
and 
I/O 
operations. 
A 
dyal 
port 
bus 
with 
controller 
enables access via the third 
bus to 2K bytes of 
static 
RAM from 
either 
the on-board 
CPU or a system 
master. 
Hence, common 
data may .be stored in on-board 
memory 
and 
may 
be accessed 
either 
by the on-board 
CPU or by system masters. 
A block diagram 
of the iSSC 
569 functional 
components 
is shown 
in Figure 
1. 
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RAM Capacity 
The iSBC 569 board contains 2K bytes of read/write 
memory using Intel 2114 static RAMs. RAM accesses 
mayoccur from either the iSBC569controller or from any 
other bus master interfaced via the MULTIBUS system 
bus. The iSBC 569 board provides addressingjumpers to 
allow the on-board RAM to reside within a one megabyte 
address space when accessed via the system bus. In 
addition, a switch is provided which allows the user to 
reservea 1K bytesegmentof on-board RAMfor useby the 
8085A CPU. This reserved RAM space is not accessible 
via the system bus and does not occupy any system 
address space. 
EPROM/ROM 
Capacity 


Two sockets for up to 16K bytes of nonvolatile read only 
memory are provided on the iSBC 569board. Nonvolatile 
memory may be added in 1K-byte increments up to a 
maximum of 2K bytes using Intel 2758 erasable and 
electrically 
reprogrammable 
ROMs (EPROMs); 
in 


2K-byte increments up to a maximum of 4K bytes using 
Intel 2316ROMs or 2716 EPROMs;in 4K byte increments 
up to 8K bytes maximum using Intel 2732EPROMs;or in 
8K-byte increments up to 16Kbytes maximum using Intel 
2364 ROMs (both sockets must contain 
same type 
ROM/EPROM). All on-board ROM/EPROM operations 
are performed at maximum processor speed. 
Universal Peripheral Interfaces (UPI-41A) 


The iSBC 569Intelligent Digital Controller board provides 
three sockets 
for user supplied 
Intel 8041A/8741A 


Universal Peripheral Interface (UPI-41A) chips. Sockets 
are also provided for the associated line drivers and 
terminators forthe UPII/Oports. 
The UPI-41A processor 


is a single chip microcomputer containing a CPU, 1K 
bytes of ROM (8041A) or EPROM (8741A), 64 bytes of 
RAM, 16programmable I/O lines,and an 8-bit timer/event 
counter. Special interface registers included in the chip 
allow the UPI-41A processor to function 
as a slave 
processor to the iSBC 569 controller 
board's 8085A 


CPU. The UPI processor allows the user to specify 
algorithms for controlling 
peripherals directly thereby 


freeing 
the 8085A for other system functions. 
For 
additional information, including UPI-41A instructions, 
refer to the UPI-41 User's Manual (Manual No. 98005041. 


Industrial Digital Processor (ISBC 941) 
The iSBC 941 Industrial Digital Processor is a 40-pin DIP 
device 
which 
provides 
the user with 
easy-to-use 


processing of digital input and output signals desired in 
many industrial automation environments. One of nine 
digital I/O functions can be selected at anyone time for 
measuring, counting, or controlling up to 16separateI/O 
lines. An additional eight utility commands allow reading 
or setting the condition of unused I/O lines. Simplex 
serial input and output modescan assembleor disassem- 
ble bytes transmitted asynchronously over TTL lines, 
including insertion and deletion of start/stop bits. The 
iSBC 941 processor plugs into any of the three UPI-41A 
sockets on the iSBC 569 board. Simple programming 
commands from the master 8085A processor can thus 
implement up to 48 lines of preprocessed digital I/O 
signals. For specific commands and further information, 
refer to the iSBC 941 Data Sheet in this document. 


Programmable 
Timers 


The iSBC569Intelligent Digital Controller board provides 
three independently 
programmable 
interval 
timer/ 


counters utilizing one Intel 8253 Programmable Interval 
Timer (PIT). The Intel 8253 PIT provides three 16-bit 
BCD or binary interval timer/counters. Each timer may 
be used to provide a time reference for each UPITM 
processor or for agroup of UPIprocessors. The output of 
each timer also connects to the 8259A Programmable 
Interrupt Controller 
(PIC) providing the capability of 


timed interrupts. All gate inputs, clock inputs, and timer 
outputs of the 8253 PIT are available at the I/O ports for 
external access. 


Timer 
Functions 
- 
In utilizing the iSBC569controller, the 


systems designer simply configures, via software, each 
timer to meetsystemsrequirements. The 8253PIT modes 
are listed in Table 1. The contents of each counter maybe 
readat any time during system operation with simple read 
operations for event counting applications. The contents 
of each counter can be read"on-the-fly" fortime stamping 
events or time clock referenced progr~m initiations. 


Function 


Interrupt on 
terminal count 


Programmable 
one-shot 


Rate 
generator 


Square-wave 
rate generator 


Software 
triggered 
strobe 


Hardware 
triggered 
strobe 


Operation 


When terminal count is reached, 
an interrupt request is generated. 


Output goes low upon receipt of 
an external trigger edge or soft- 
ware command and returns high 
when terminal count is reached. 
This function is retriggerable. 


Divide by N counter. The output 
will go low for one input clock cy- 
cle, and the period from one low- 
going pulse to the next is N times 
the input clock period_ 


Output will remain high until one- 
half 
the count 
has been com- 


pleted, and go low for the other 
half of the count. 


Output 
remains high until 
soft- 


ware loads count' (N). N counts 
after count is loaded, output goes 
low for one input clock period. 


Output goes low for one clock pe- 
riod N counts after rising edge on 
counter trigger input. The counter 
is retriggerable. 


On a jumper selectable basis, the 
clock 
input 
becomes 
an 
input 


from the external 
system. CPU 


may read the number of events oc- 
curring after the counting 
"win- 


dow" has been enabled or an in- 
terrupt may be generated after N 
counts occur in the system. 


Interrupt Capability 


The 
iSSC 
569 
Intelligent 
Digital 
Controller 
provides 
interrupt 
service for up to 12 interrupt 
sources. 
Any of the 
12 sources 
may interrupt 
the on-board 
processor. 
Four 
interrupt 
levels 
are handled 
directly 
by the 8085A 
CPU 


and 
eight 
levels 
are 
serviced 
from 
an 
Intel 
8259A 
Programmable 
Interrupt 
Controller 
(PIC) 
routing 
an 
interrupt 
request 
output 
to the INTR Input 
of the 8085A. 


8085A 
Interrupt 
- 
Each of four 
direct 
8085A 
interrupt 


inputs 
has a unique 
vector 
memory 
address. 
An 8085A 
jump instruction 
at each of these addresses then provides 
software 
linkage 
to 
interrupt 
service 
routines 
located 


independently 
anywhere 
in the memory. 


8259A 
Interrupts 
- 
The eight 
interrupt 
sources 
originate 


from 
both on-board 
controller 
functions 
and the system 
bus: 


UPI-41A 
Processors 
- 
one interrupt 
from 
each of three 
UPI processor 
sockets. 


8253 PIT - 
one interrupt 
from each of three timer outputs. 


MUL TISUS 
System 
Sus 
- 
one 
of eight 
MUL TISUS 


Interrupt 
lines 
may be jumpered 
to either 
of two 8259A 
PIC Interrupt 
Inputs. 


Programmable 
Reset - 
The iSSC 569 Intelligent 
Digital 
Controller 
board 
has a programmable 
output 
latch used 


to control 
on-board 
functions. 
Three of the outputs 
are 


connectM 
to separate 
UPI-41A 
RESET inputs. 
Thus, the 
user can reset any or all of the UPI-41A 
processors 
under 


software 
control. 
A fourth 
latch 
output 
may be used to 


generate 
an 
interrupt 
request 
onto 
the 
MUL TISUS 


interrupt 
lines. 
A fifth latch output 
is connected 
to a Iight- 


emitting 
diode 
which 
may 
be 
used 
for 
diagnostic 
purposes. 


Expansion Capabilities 


When 
the iSSC 
569 controller 
is used as a single 
board 
digital 
controller, 
memory 
and 
I/O 
capacity 
may 
be 
expanded 
using 
Intel MUL TISUS 
compatible 
expansion 
boards. 
In this mode, no other bus masters 
may be in the 
system. 
Memory 
may be expanded 
to a64K byte capacity 
by adding 
user specified 
combinations 
of RAM boards, 


EPROM 
boards, 
or 
combination 
boards. 
Input/output 
capacity 
may 
be 
increased 
by 
adding 
I/O 
expansion 
boards. 
Multiple 
iSSC 569 boards 
may be included 
In an 


expanded 
system 
using one iSSC 569 Intelligent 
Digital 


Controller 
as the system 
master 
and additional 
control- 
lers as intelligent 
slaves. 


Intelligent Slave Programming 


When used as an intelligent 
slave, the iSSC 569 controller 


appears 
as an additional 
RAM memory 
module. 
System 
bus masters communicate 
with the iSSC 569 board as if it 
were 
just 
an extension 
of system 
memory. 
To simplify 
this 
communication, 
the 
user 
has 
been 
given 
some 
specific 
tools: 


Flag Interrupt 
- 
The Flag Interrupt 
is generated 
any time 
a write command 
is performed 
by an off-board 
CPU to the 
first location 
of iSSC 569 RAM. 
This interrupt 
provides 
a 
means 
for 
the 
master 
CPU 
to 
notify 
the 
iSSC 
569 
controller 
that 
it wished 
to establish 
a communications 
sequence. 
The 
flag 
interrupt 
is cleared 
when 
the 
on- 


board 
processor 
reads the first 
location 
of its RAM. 
In 


systems 
with 
more 
than 
one 
intelligent 
slave, 
the 
flag 
interrupt 
provides 
a unique 
interrupt 
to each slave outside 
the normal 
MUL TISUS 
interrupt 
lines (INTO/-INT?/). 


RAM - 
The on-board 
2K byte RAM area that is accessible 
to both an off-board 
CPU and the on-board 
8085A may be 
configured 
for system 
access 
on any 2K boundary. 


MUL T1BUS Interrupts 
- 
The third tool to improve 
system 


operation 
as an 
intelligent 
slave 
is 
access 
to 
the 


MUL TISUS 
interrupt 
lines. 
The iSSC 569 controller 
can 
both respond 
to interrupt 
signals 
from an off-board 
CPU, 


and generate 
an interrupt 
to the off-board 
CPU via the 


system 
bus. 


System Development 
Capability 


Software 
development 
for the iSSC 569 Intelligent 
Digital 


Controller 
board 
IS supported 
by the 
Intellec@ 
Micro- 
computer 
Development 
System 
including 
a resident 


macroassembler, 
text 
editor, 
system 
monitor, 
a linker, 


object 
code 
locator, 
and 
Library 
Manager. 
In addition, 
both 
PLiM 
and 
FORTRAN 
language 
programs 
can 
be 
compiled 
to run 
on the iSSC 
569 board. 
A unique 
in- 


circuit 
emulator 
(ICE-85™) 
option 
provides 
the capability 
of developing 
and 
debugging 
software 
directly 
on the 
iSSC 
569 
board. 
This 
greatly 
simplifies 
the 
design, 


development, 
and debug 
of iSSC 569 system 
software. 


SPECIFICATIONS 


SOSSA CPU 


Word 
Size - 
8, 16 or 24 bits 


Cycle 
Time 
- 
1.30 Ilsec 
± .1% for 
fastest 
executable 
instruction; 
i.e., four clock 
cycles. 


Clock 
Rate - 
3.0? MHz ± .1% 


System Access Time 


Dual 
port memory 
- 
725 nsec 


Memory Capacity 


On-board 
ROM/EPROM 
- 
2K, 4K, 8K, or 16K bytes of 
user installed 
ROM or EPROM 


On-board 
RAM 
- 
2K 
bytes 
of 
static 
RAM. 
Fully 


accessible 
from on-board 
8085A 
Separately 
addressable 
from 
system 
bus. 


Off·board 
expansion 
- 
up to 64K bytes of EPROM/ROM 


or RAM capacity. 


I/O Capacity 


Parallel- Timers 
- 
Three 
timers, 
with 
independent 
gate 
input, 
clock 
input, 
and 
timer 
output 
user- accessible. 
Clock 
inputs 
can be strapped 
to an external 
source-or 
to 
an 
on-board 
1.3824 
MHz 
reference. 
Each 
timer 
is 
connected 
to a 8259A Programmable 
Interrupt 
Controller 
and may also be optionally 
connected 
to UPI processors. 


UPI-I/O 
- 
Three UPI-41~ 
interfaces, 
each with two 8-bit 
I/O ports plus the two UPI Test Inputs. 
The8-bit 
ports are 
user-configurable 
(as inputs or outputs) 
in groups 
of four. 


Serial-1 
TTL compatible 
serial channel 
utilizing 
SID and 
SOD lines of on-board 
8085A CPU 
On-Board Addressing 


All communications 
to the 
UPI-41A 
processors, 
to the 
programmable 
reset 
latch, 
to 
the 
timers, 
and 
to the 
interrupt 
controller 
are via read and write commands 
from 
the on-board 
8085A 
CPU. 


Memory Addressing 


On-board 
ROM/EPROM 
- 
o-07FF 
(using 2758 EPROMs); 


O-OFFF (using 2716 EPROMs or 2316 ROMs); o-lFFF 
(using 
2732 EPROMs); G-3FFF (using the 2364 ROMs) 


On-board 
RAM - 
8000-87FF 
System 
access 
- 
any 2K 
increment 
00000-FF800 
(switch 
selectable); 
1K bytes may 
be disabled 
from 
bus access 
by switch 
selection. 


I/O Addressing 


Source 
Addresses 


8253 
OEOH-OE3H 
UPIO 
OE4H-OE5H 
UPll 
OE6H-OE7H 


UPI2 
OE8H-OE9H 
PROGRAMMABLE 
RESET 
OEAH-OEBH 
8259A 
OECH OEDH 


Timer Specifications 


Input 
frequencies 
- 
jumper 
selectable 
reference 


Internal: 
1.3824 MHz ± .1% (.723I'sec, 
nominal) 
External: 
User supplied 
(2 MHz maximum) 


Output 
Frequencies 
(at 13824 
MHz) 


Function 
Mini 
Max' 


Real-lime 
1.45 JJsec 
474 
msec 
mterrupt interval 


Rate Generator 
21.09 Hz 
691.2 KHz 
(frequency) 


1. Single 16 


Mblt binary count 


Interfaces 


MUL TIBUSTM 
Interface 
- 
All 
signals 
compatible 
with 


iSSC and MUL TISUS 
architecture 


Parallel 
I/O - 
All signals 
TTL 
compatible 


Interrupt 
Requests 
- 
All TTL 
compatible 


Timer 
- 
All signals 
TTL compatible 


Serial 
I/O - 
All signals 
TTL 
compatible 


Connectors 


Interface 
Pins 
Centers 
Mating 
Connectors 
(qly) 
(in.) 


Bus 
86 
0.156 
Viking 
3KH43/9AMK12 


Parallel 
110 
50 
0.1 
3M 3415.000 or 
TI H312125 


Physical Characteristics 


Width 
- 
30.48 cm (12.00 inches) 


Depth 
- 
17.15 cm (6.75 inches) 
Thickness 
- 
1.27 cm (0.50 inch) 
Weight 
- 
3.97 gm (14 ounces) 


Electrical Characteristics 


DC Power 
Requirements 
- 
+ 5V @ 2.58A 
with 
no op· 


tional 
devices 
installed. 
For each 8741A add 135 mA. For 


each 
220/330 
resistor 
network, 
add 60 mA. Add the fol- 


lowing 
for each 
EPROM/ROM 
installed. 


+S.OV Current 
Requirement 


Type 
1ROM 
2ROMS 


2758 
100 mA 
125 mA 


2716 
100 mA 
125 mA 


2316E 
120 mA 
240 mA 


2732 
40 mA 
55 mA 


2364 
40 mA 
55 mA 


Line Drivers and Terminators 


I/O Drivers 
- 
The following 
line drivers 
are all compatible 


with 
the 
I/O 
driver 
sockets 
on the 
iSSC 
569 Intelligent 


Digital 
Controller 


Driver 
Characteristic 
Sink Current (mA) 


7438 
I.OC 
48 


7437 
I 
48 
7432 
NI 
16 


I 


7426 
I.OC 
16 


7409 
NI.OC 
16 


7408 
NI 
16 


j 


7403 
I.OC 
16 


- 


7400 
I 
16 
- 


2200 
----"/V'v-- 
---, 


3300 
I 
~ 
- 
_---l 
- 
---e esec 901 OPTION 


Environmental 
Characteristics 


Operating 
Temperature 
- 
O°C to 55°C 
(32°F 
to 131°F) 


Relative 
Humidity 
- 
To 90% without 
condensation 


Reference Manuals 


502180 
- 
iSBC 
569 Intelligent 
Digital 
Controller 
Board 


Hardware 
Reference 
Manual 
(NOT SUPPLIED) 


503100 
- 
iSBC 
941 
Digital 
Signal 
Processor 
User's 


Guide 
(NOT SUPPLIED) 


Reference 
manuals 
are shipped 
with each product 
only if 
designated 
SUPPLIED 
(see above). 
Manuals 
may 
be 
ordered 
from 
any 
Intel 
sales 
representative, 
distributor 


office 
or from 
Intel 
Literature 
Department, 
3065 Bowers 


Avenue, 
Santa 
Clara, 
California 
95051. 


Part Number 


SBC 569 


Description 


Intelligent 
Digital 
Controller 


iSBC 556 
OPTICALLY ISOLATED I/O BOARD 


• Provisions for plug-in, optically isolated 
receivers, drivers, and terminators 


• Up to 48 digital optically isolated 


input/output data lines 
• Voltate/current 
levels 
- 
Input up to 48V 
- 
Output up to 30V, 60 mA 


• Choice of 


- 
24 fixed input lines 


- 
16 fixed output lines 


- 
8 programmable lines 


The iSBG 556 OpticallY Isolated 1/0 Board provides 48 digital input/output lines with isolation between process ap- 
plication or peripheral device and the iSBG80 series single board computers. The iSBG 556 contains two 8255A pro· 
grammable interface devices, and sockets for user supplied optically isolated drivers, receivers, and input resistor ter· 
minators, together with common interrupt logic and iSBG80 bus interface logic. Input signals can be single-ended or 
differential types with user defined input range (resistor terminator and opto-isolated receiver selection), allowing 
fleXibility in design of voltage and threshold levels. The output allows user selection of Opto-Isolated Darlington Pair 
which can be used as an output driver either as an open collector or current switch. 


Resistor 
Dual 
Terminator 
Opto-Isolator 
Port No. 
Pac-Rp 
Driver 


X=I/O Base 
Type of 
Lines 
16·Pin DIP 
8-Pin DIP 
7438 
Pull-Up 


Address 
I/O 
(qty) 
Bourns 
Monsanto 
or Equivalent 
iSBC' 902 


MCT66 
4116R·00 
or Equivalent 
or Equivalent 


X+O 
Input 
8 
1 
4 
- 
X+1 
Output 
8 
- 
- 
X+2 
Input/ 
8 
1 
- 
Control 
X+4 
Input 
8 
1 
4 
- 


X+5 
Output 
8 
- 
X+6 
Inpull } 
Output 
8 
1 if input 
2 if output 
2 if input 
X+7 
Control 


Number of Lines 


24 input lines 
16 output lines 
8 programmable lines: 4 input - 
4 output 


110Interface 
Characteristics 
Line·to·Line Isolation - 
235V DC or peak AC 
Input/Output Isolation - 
500V DC or peak AC 


USER·SUPPLIED 


DUAL 
OPTC-ISOLATOR 
USER·SUPPLIED 
D 


r 
----- 
i--' 
RESISTOR 


: 
R 
p 


: 16P1N 
DIP 
,_, 
;SBC 


I 
H 


D~*i*&==·i: 
L 
~ 
L_-l 


Ap 
DETERMINES 
VOLTAGE 
AND 
CURRENT 
RANGE. 


Bus Interface 
Characteristics 
All data address and control commands are iSBC 80 
bus compatible. 


8255'1 


ABC 


8255'2 


ABC 


Where: 
base address is from OOHto 1FH (jumper selectable) 


Part Number 
Description 


SBC 556 
Optically Isolated I/O Board 


Interface 
Pins 
Centers 
Mating 
Connectors 
(qty) 
In. 
em 


PI iSBe 
bus 
86 
0.156 
Viking 
3KH4319AMK12 


J116 
fixed 
input 
& 
50 
0.1 
3M 3415'()()() or 
8 fixed output lines 
TI M312125 


J28 
fixed 
output, 
8 
50 
0.1 
3M 3415.QOOor 
fixed output, 
& 8 
TI M312125 
programmable 
input/output 
lines 


Physical Characteristics 
Width - 
12.00 in. (30.48cm) 


Height - 
6.75 in. (17.15cm) 


Depth - 
0.50 in. (1.27 cm) 


Weight - 
12 oz (397.3gm) 


Electrical 
Characteristics 
Average DC Current 


Vee= + 5V± 5%, 1.0A without user supplied isolated 
receiver/driver 
Ice = 1.6Amax with user supplied isolator receiver/driver 


Environmental 
Characteristics 


Temperature - 
O°C to 55°C 
Relative Humidity - 
0 to 90%, non-condensing 


Reference Manual 


502170 - 
iSBC 556 Hardware Reference Manual (NOT 


SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 Bowers 
Avenue, Santa Clara, California 95051. 


iSBC 519 (or pSBC 519*) 
PROGRAMMABLE 
I/O EXPANSION 
BOARD 


• iSBC I/O expansion via direct 
MULTIBUS Interface 


• 72 programmable I/O lines with sockets 
for interchangeable 
line drivers and 
terminators 


• Jumper selectable I/O port addresses 


• Jumper selectable 0.5,1.0,2.0, 
or 4.0 ms 
interval timer 


• Eight maskable interrupt request lines 
with priority encoded and program· 
mabie interrupt algorithms 


The iSBC 519 Programmable I/O Expansion Board is a member of Intel's complete line of iSBC memory and I/O expan- 
sion boards. The iSBC 519 interfaces directly to any iSBC single board computer via the system bus to expand input 
and output port capacity. The iSBC 519 provides 72 programmable I/O lines. The system software is used to configure 
the I/O lines to meet a wide variety of peripheral requirements. The flexibility of the I/O interface is further enhanced by 
the capability of selecting the appropriate combination of optional line drivers and terminators to provide the required 
sink current, polarity, and driveltermination 
characteristics 
for each application. Address selection is accomplished 
by using wire-wrap jumpers to select one of 16 unique base addresses for the input and output ports. The board oper- 
ates with a single + 5V power supply. 


The 72 programmable 1/0 lines on the iSSC 519 are im- 
plemented 
utilizing 
three 
Intel 
8255 programmable 
peripheral interfaces. The system software is used to 
configure the I/O lines in any combination of unidirec- 
tional input/output 
and bidirectional 
ports indicated in 


Table 1. In order to take full advantage of the large 
number of possible I/O configurations, 
sockets are pro- 


vided 
for 
interchangeable 
I/O line 
drivers 
and ter- 
minators. The 72 programmable I/O lines and signal 
ground lines are brought out to three 50-pin edge con- 
nectors that mate with flat, round, or woven cable. 


Interval Timer 


Typical 
I/O read access 
time 
is 350 nanoseconds . 


Typical 110 read/write cycle time is 450 nanoseconds. 
The interval timer provided on the iSSC 519 may be used 
to generate real time clockinlj in systems requiring the 
periodic monitoring of 110 functions. The time interval is 
derived from the constant clock (BUSCCLK)and the tim- 
ing interval is jumper selectable. Intervals of 0.5, 1.0,2.0, 
and 4.0 milliseconds 
may be selected when an iSSC 


single board computer is used to generate the clock. 
Other timing intervals may I>egenerated if the user pro- 
vides a separate constant clock reference in the system. 


Eight·Level 
Vectored 
Interrupt 


An Intel 8259 programmable interrupt controller 
(PIC) 


provides vectoring for eight interrupt levels. As shown 
in Table 2, a selection of three priority processing algo- 
rithms is available to the system designer so that the 


. 
Mode of Operation 


Unidirectional 
Lines 
Input 
OutDut 
Bidirectional 
Control 
Ports 
(qty) 
Latched & 
Latched & 
Unlatched 
Strobed 
Latched 
Strobed 


1,4,7 
8 
X 
X 
X 
X 
X 


2,5,8 
8 
X 
X 
X 
X 


3,6,9 
4 
X 
X 
Xl.2.3 


4 
X 
X 
Xl.2.3 


Not •• 


1. Part of port 3 must be used as a control port when either port 1 or port 2 are used as a latched and strobed input 
Of a latched and strobed output 
port or port 
1 is used as a bidirectional 
port. 


2. Part of port 6 must be used as a control port when either port 4 or port 5 are used as a latched and strobed input 
Of a latched and strobed output 
port or port 4 is used as a bidirectional 
port. 


3. Part of port 9 must be used as a control port when either port 7 or port 8 are used as a latched and strobed input or a latched and strobed output 
port or port 7 is used as a bidirectional 
port. 


3 


INTEARUPT 


AEQUEST 
LINES 


1 


INTERRUPT 


REQUEST 


LINE 


6 


INTERRUPT 


REQUEST 


LINES 


Algorithm 
Operation 


Fully nested 
Interrupt request line priorities 
fixed 
at 
0 
as 
highest, 
7 
as 
lowest. 


Auto-rotating 
Equal priority. Each level, after 
receiving service, becomes the 
lowest priority 
level until next 
interrupt occurs. 


Specific priority 
System 
software 
assigns 
lowest priority level. Priority of 
all other levels are based in se- 
quence 
numerically 
on 
this 
assignment. 


manner in which requests are serviced may be config- 
ured to match system requirements. Priority assign- 
ments may be reconfigured dynamically via software at 
any time during system operation. The PIC accepts 
interrupt requests from the programmable parallel I/O 
interfaces, the interval timer, or direct from peripheral 
equipment. The PIC then determines which 
of the 


whether 
thiS request 
IS OTnlgflt:H 
fJflUlllY 
1I1C:lll 
1I1C 
ICYII;;iI 


currently being serviced, and if appropriate, issues an 
interrupt 
to the system master. Any combination 
of 
interrupt 
levels may be masked through storage, via 
software, of a single byte to the interrupt mask register 
of the PIC. 


Interrupt Request Generation - 
Interrupt requests may 
originate from 10 sources. Six jumper selectable inter- 
rupt requests can be automatically 
generated by the 


programmable peripheral interfaces when a byte of in- 
formation 
is ready to be transferred 
to the system 
master (i.e., input buffer is full) or a character has been 
transmitted 
(i.e., output data buffer is empty). Three 
interrupt request lines may be interfaced to the PIC 
directly from user designated peripheral devices via the 
I/O edge connectors. One interrupt request may be gen- 
erated by the interval timer. 


Bus Line Drivers - 
The PIC interrupt request output 


line may be jumper selected to drive any of the nine in- 
terrupt lines on the MULTIBUS.Any of the on-board re- 
quest lines may also drive any interface interrupt line 
directly via jumpers and buffers on the board. 


8255 
8255 
8255 


Pori 
1 
2 
3 
No.1 
4 
5 
6 
No.2 
7 
8 
9 
No.3 
Control 
Control 
Control 


Address 
XO Xl 
X2 
X3 
X4 
X5 
X6 
X7 
X8 
X9 
XA 
XB 


Interrupts 
Register Addresses (hex notation, I/O address space) 
XD 
Interrupt request register 


XC 
In-service register 


XD 
Mask register 


XC 
Command register 
XD 
Block address register 


XC 
Status (polling register) 


Note 
Several registers 
have the same physical 
address; 
sequence 
of access and 
one data bit of control 
word determines 
which 
register witl respond. 


Ten interrupt request lines may originate from the pro- 
grammable 
peripheral 
interface 
(6 
lines), 
or 
user 


specified devices via the I/O edge connector (3 lines), or 
interval timer (1 line). 


Interval Timer 
Output Register - 
Timer interrupt register output is 
cleared by an output instruction to I/O address XE or 
XF1. 


Timing 
Intervals - 
500, 1,000, 2,000, and 4,000 ms 
± 1%; jumper selectable2. 


Notes 


1. X is any hex digit assigned 
by jumper selection. 


2. Assumes 
constant 
clock (CCLK) frequency 
of 9.216 MHz ± 1%.-- 


Interfaces 
Bus - 
All signals TTL compatible 


Parallel I/O - 
All signals TTL compatible 


Interrupt Requests - 
All TTL compatible 


Intertace 
Pins 
Centers 
Mating 
Connectors 
(qly) 
(In.) 


Bus 
86 
0.156 
VIkIng 
3KH43J9AM..t<..:3.... 


Parallel 1/0 
50 
0.1 
3M 3415·000 or 
TI H312125 


Serial 1/0 
26 
0.1 
3M 3462·000 or 
TI H3l2113 
.- 


Auxiliary' 
60 
0.1 
AMP 
PE5-14559 
or 


TI H311130 -- 


Note 
1. Connector 
heights 
and wlrewrap 
pin lengths 
are not guaranteed 
to 


conform 
to Intel OEM or System packaging. 


Line Drivers and Terminators 
I/ODrivers- 
Thefollowing line driversand terminators are 
compatible with all the I/O driver sockets on the iSBC 
519: 


Driver 
Characteristic 
Sink Current (mA) 


7438 
I.OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
I.OC 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
1 
16 


Note 


I = Inverting; 
NI = non-inverting: 
OC 
= open·collector. 


220Q 
.5V_~;: 
I 


220QI330Q 1- 
~~: 
---~~ 
iSBC 901 OPTION 


....L 


Ports 1,4, and 7 may use any of the drivers or terminators 
shown above for unidirectional (input or output) port con· 
figurations. 
Either terminator and the following bidirec- 
tional drivers and terminators may be used for ports 1,4, 
and 7 when these ports are used as bidirectional 
ports. 


Bidirectional 
Drivers 


Characteristic 


NI.TS 


I,TS 


Sink 
Curront 
(mA) 


25 


50 


Note 


I = inverting; 
NI :; non·inverting; 
TS = three-state. 


Terminators (for ports 1,4, and 7 when used as bidirec· 
tional ports) 


Supplier 
Product 
Series 


CTS 
760· 


Dale 
LDP14k·02 


Beckman 
899·1 


Characteristic 


Tri-state 


Tri-state 


Sink Curront 
(mAl 


50 


25 


Physical Characteristics 
Width - 
12.00 in. (30.48 cm) 


Height - 
6.75 in. (17.15 cm) 


Depth - 
0.50 in. (1.27 cm) 


Weight - 
1402 (397.3 gm) 


Electrical 
Characteristics 
Average DC Current 


Without 
Torrnlnollon 
1 


Ice; 
1.5Amax 


With 
Torrnlnollon2 


3.5A max 


Note 


1. 
Does not include 
power 
required 
for optional 
If0 drivers 
and If0 ter- 


minators. 


2. 
With 
18 220Q/330Q Input terminators 
installed, 
all terminator 
inputs 


low. 


Environmental 
Characteristics 
Operating Temperature - 
O·C to + 55·C 


9800385B - 
iSBC 519 hardware Reference Manual (NOT 


SUPPLIED) 


Manuals may be ordered from any Intel sales represen· 
tative, distributor 
office or from Intel Literature Depart· 


ment, 3065 Bowers Avenue, Santa Clara, California 
95051. 


Part Number 


SBC 519 
Description 


Programmable I/O Expansion 
Board 


iSBC 517 
COMBINATION 
I/O EXPANSION BOARD 


• 48 programmable 1/0 lines with sockets 
for interchangeable 
line drivers and 


terminators 


• Synchronous/asynchronous 
communi· 
cations interface with RS232C drivers 
and receivers 


• Eight maskable interrupt request lines 
with a pending interrupt register 


The iSBC 517 Combination I/O Expansion Board is a member of Intel's complete line of iSBC memory and I/O expan- 
sion boards. The board interfaces directly with any iSBC single board computer via the system bus to expand serial 
and parallel I/O capacity. The combination I/O board contains 48 programmable parallel I/O lines. The system software 
is used to configure the I/O lines to meet a wide variety of system peripheral requirements. The flexibility 
of the I/O in- 
terface is significantly 
enhanced by the capability of selecting the appropriate combination of optional line drivers and 
terminators to provide the required sink current, polarity, and drive/termination characteristics 
for each application. A 
programmable RS232Ccommunications 
interface is provided on the iSBC 517. This interface may be programmed by 


the system software to provide virtually any asynchronous or synchronous serial data transmission technique (includ- 
ing IBM Bi-Sync). A comprehensive RS232Cinterface to CRTs, RS232Ccompatibie cassettes, and asynchronous and 
synchronous modems is thus on the board. An on-board register contains the status of eight interrupt request lines 
which may be interrogated from the system bus, and each interrupt request line is maskable under program control. 
The iSBC 517 also contains a jumper selectable 1 ms interval timer and interface logic for eight interrupt request lines. 


Programming 
Flexibility 


The 
48 programmable 
I/O lines 
on 
the 
iSBC 
517 are 
implemented 
utilizing 
two 
Intel 
8255 
programmable 
peripheral 
interfaces. 
The 
system 
software 
is used 
to 


configure 
these 
programmable 
I/O lines 
in any 
of the 


combinations 
of 
unidirectional 
input/output, 
and 
bi- 
directional 
ports 
indicated 
in Table 
1. In order 
to take 
full 
advantage 
of the large 
number 
of possible 
I/O con- 
figurations, 
sockets 
are 
provided 
for 
interchangeable 


I/O line drivers 
and terminators 
to provide 
the required 


sink 
current, 
poiarity, 
and driveltermination 
character- 
istics 
for 
each 
application. 
The 
48 programmable 
I/O 
lines 
and 
signal 
ground 
lines 
are 
brought 
out 
to 
two 
50-pin 
edge 
connectors 
that 
mate 
with 
flat, 
round, 
or 


woven 
cable. 
Typical 
·1/0 
read 
access 
time 
is 
280 
nanoseconds. 
Typical 
I/O 
read 
cycle 
time 
is 
600 
nanoseconds. 


Communications 
Interface 


The 
programmable 
communications 
interface 
on 
the 


iSBC 
517 is provided 
by an 
Intel 
8251 
Universal 
Syn- 


chronous/Asynchronous 
Receiver/Transmitter 
(USART). 
The USART can be programmed 
by the system 
software 


to 
select 
the 
desired 
asynchronous 
or 
synchronous 
serial 
data 
transmission 
technique 
(including 
IBM 
Bi- 


Sync). The mode of operation 
(i.e., synchronous 
or asyn- 


chrOnous), 
data format, 
control 
character 
format, 
parity, 


and asynchronous 
serial 
transmission 
rate are all under 
program 
control. 
The 8251 provides 
fUll duplex, 
double- 
buffered 
transmit 
and 
receive 
capability, 
and 
parity, 


overrun, 
and 
framing 
error 
detection 
are 
all 
incor- 
porated 
in the 
USART. 
The comprehensive 
RS232C 
in- 
terface 
on 
the 
board 
provides 
a 
direct 
interface 
to 
RS232C compatible 
equipment. 
The RS232C serial 
data 
lines and signal 
ground 
lines 
are brought 
out to a 26-pin 
edge connector 
that mates 
with 
RS232C compatible 
flat 


or round 
cables. 


Interrupt 
Request Lines 


Interrupt 
requests 
may 
originate 
from 
eight 
sources. 


Four 
jumper 
selectable 
interrupt 
requests 
can 
be 


automatically 
generated 
by 
the 
programmable 


peripheral 
interface 
when a byte of information 
is ready 


to be transferred 
to the CPU (i.e., input 
buffer 
is fUll) or a 


character 
has been transmitted 
(i.e., output 
data 
buffer 
is empty). 
Two jumper 
selectable 
interrupt 
requests 
can 
be 
automatically 
generated 
by 
the 
USART 
when 
a 


character 
is ready 
to 
be transferred 
to 
the 
CPU 
(i.e., 


receive 
buffer 
is full) 
or 
a character 
has 
been 
trans- 
mitted 
(transmit 
buffer 
is empty). 
These 
six 
interrupt 
request 
lines 
are all 
maskable 
under 
program 
control. 


Two 
interrupt 
request 
lines 
may 
be interfaced 
directly 


from user designated 
peripheral 
devices 
via the I/O edge 
connector. 
An on-board 
register 
contains 
the status 
of 


all 
eight 
interrupt 
request 
lines, 
and 
may 
be 
inter- 
rogated 
by 
the 
CPU. 
Each 
interrupt 
request 
line 
is 


U 


;NTERRUPT 


REQUEST 


LINES 


ADDRESS 
BUS 


DATA 
BUS 


CONTROL 
BUS 
} 


~MULnBUS 
ylNTERFACE 


Mode of Operation 


Unidirectional 


Ports 
Lines 
Input 
Output 
Bidirectional 
Control 
(qty) 
Latched 
& 
Latched 
& 
Latched 
Unlatched 
Strobed 
Strobed 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 


3 
4 
X 
X 
X1 


4 
X 
X 
X1 


4 
8 
X 
X 
X 
X 
X 


5 
8 
X 
X 
X 
X 


6 
4 
X 
X 
X2 


4 
X 
X 
X2 


Notes 


1. Part of port 3 must be used as control 
port when either 
port, 
or port 2 are used as a latched 
and strobed 
input or a latched 
and strobed 
output 
port 
or port 
1 is used as a bidirectional 
port. 


2. Part of port 6 must 
be used as a control 
port when either 
port 4 or port 5 are used as a latched 
and strobed 
input 
or a latched 
and strobed 
output 
port or port 4 is used as a bidirectional 
port. 


maskable 
under 
program 
control. 
Routing 
for the eight 


interrupt 
request 
lines 
is jumper 
selectable. 
They 
may 


be ORed to provide 
a single 
interrupt 
request 
line for the 


iSBC 80/10B, or they may be individually 
provided 
to the 


system 
bus 
for 
use 
by other 
iSBC 
single 
board 
com- 
puters. 


Interval Timer 


Each board 
contains 
a jumper 
selectable 
1 ms interval 


timer. 
The 
timer 
is enabled 
by jumpering 
one 
of 
the 
interrupt 
request 
lines from 
the 110 edge connector 
to a 


1 ms interval 
interrupt 
request 
signal 
originating 
from 


the baud 
rate generator. 


SPECIFICATIONS 


1/0 Addressing 


8255 
8255 
USART 
USART 


Port 
1 
2 
3 
4 
5 
6 
No.1 
No.2 
Data 
Control 
Control 
Control 


Address 
X4 
X5 
X6 
X8 
X9 
XA 
X7 
XB 
XC 
XD 


Note 


X is any hex digit 
assigned 
by Jumper selection. 


1/0 Transfer Rate 


Parallel 
- 
Read or write 
cycle 
time 
760 ns max 


Serial 
- 
(USART) 


Baud Rate (Hz) 


Frequency 
(kHz) 


Synchronous 
Asynchronous 
(Jumper 
Selectable) 
(Program Selectable) 


~16 
~64 


1536 
- 
9600 
2400 
76.8 
- 
4800 
1200 
38.4 
38400 
2400 
600 
19.2 
19200 
1200 
300 
9.6 
9600 
600 
150 
4.8 
4800 
300 
75 
6.98 
6980 
- 
110 


Serial Communications 
Characteristics 


Synchronous 
- 
5-8 bit characters; 
internal 
or external 
character 
synchronization; 
automatic 
sync 
insertion. 


Asynchronous 
- 
5-8 bit 
characters; 
peak 
characters 


generation; 
1, 1'12, or 2 stop 
bits; 
faise 
start 
bit detec- 


tors. 


Interrupts 


Eight 
interrupt 
request 
lines 
may originate 
from the pro- 


grammable 
peripheral 
interface 
(4 lines), 
the USART (2 


lines), or user specified 
devices 
via the 110 edge connec- 


tor (2 lines) or interval 
timer. 


Interrupt 
Register Address 


Xl 
Interrupt 
mask 
register 


XO 
Interrupt 
status 
register 


Note 


X IS any hex digit assigned by jumber selection. 


Timer Interval 


1.003 ms ± 0.1 % when 
110 baud 
rate is selected 


1.042 ms ± 0.1 % for all other 
baud 
rates 


Interfaces 
Bus - 
All signals TTl compatible 


Parallel 110 - 
All signals TTl compatible 


Serial 1/0 - 
RS232C 
Interrupt Requests - 
All TTl compatible 


Interface 
Pins (qly) 
Centers 
(in.) 
Mating 
Connectors 


Bus 
86 
0.156 
COC VPBOI E43AOOA1 


Paraliell/O 
50 
0.1 
3M 3415-000 or 
TI H312125 


Serial If0 
26 
0.1 
3M 3462-000 or 
TI H312113 


Auxiliary 1 
60 
0.1 
AMP PE5-14559 
or 
TI H311130 


Note 


1. Connector 
heights 
and wire-wrap 
pin lengths 
are not guaranteed 
to 
conform 
to Intel OEM or system 
packaging. 
Auxiliary 
connector 
is used 


for test purposes 
only. 


Line Drivers and Terminators 


1/0 Drivers - 
The following line drivers and terminators 


are compatible with all the 1/0 driver sockets on the 
iSBC 517: 


Driver 
Characteristic 
Sink Current (mA) 


7438 
I,OC 
48 
7437 
I 
48 


7432 
NI 
16 


7426 
I,OC 
16 


7409 
NI,OC 
16 
7408 
NI 
16 
7403 
I.OC 
16 


7400 
I 
16 


Note 


I = inverting; 
NI = non·inverting; 
DC = open-collector. 


Ports 1 and 4 have 25 mA totem-pole drivers and 1 kQ 
terminators. 


2200 
+sv-~;o-: -I 


220Qf330Ql-~-----'\~~: 
----l---o 
iSBC901 OPTION 


Function 
Characteristic 
Sink Current (mA) 


Data 
Tri·state 
50 


Commands 
Tri·state 
25 


Physical Characteristics 
Width - 
12.00 in. (30.48cm) 


Height - 
6.75 in. (17.15em) 


Depth - 
0_50in. (1.27 em) 


Weight - 
14 oz (397.3 gm) 


Electrical 
Characteristics 
Average DC Current 
Vcc= 
+5V ±5'10 


Voo=+12V±5% 
VAA = 
- 12V ± 5% 


Icc = 2.4 mA max 


100= 
40 mA max 


IAA = 6QmA max 


Note 


Does not include 
power required 
for optional 
110 drivers and I/O ter- 


minators. 
With 
eight 
220Q/330Q input 
terminators 
Installed, 
all ter- 


minator inputs low. 


Environmental 
Characteristics 


Operating Temperature - 
O'C to + 55'C 


9800388B- 
iSBC 517 hardware Reference Manual (NOT 


SUPPLIED) 


Manuals may be ordered from any Intel sales represen- 
tative, distributor office or from Intel Literature Depart- 
ment, 3065 Bowers Avenue, Santa Clara, California 
95051. 


ORDERING 
INFORMATION 


Part Number 
Description 


SBC 517 
Combination I/O Expansion Board 


iSBX 488™ 
GPIB MUL TIMODULE 
BOARD 


• Complete 
IEEE 488·1978 talkerllistener 
functions 
including: 
- 
Addressing, 
handshake 
protocol, 
service 
request, 
serial and parallel 
polling 
schemes 


• Complete 
IEEE 488·1978 controller 
functions 
including: 
- 
Transfer 
control, 
service 
requests 
and remote 
enable 


• Simple 
read/write 
programming 


• Software 
functions 
built 
into VLSI 


hardware 
for high performance, 
low 
cost and small size 


• Standard 
iSBX™ Bus interface 
for easy 
connection 
to Intel iSBC™ boards 


• IEEE 488·1978 standard 
electrical 
in· 
terface 
transceivers 


The Intel iSBX 488 GPIB Talker/Listener/Controller 
Multimodule 
board provides 
a standard 
interface 
from 
any Intel iSBC board equipped 
with an iSBX connector 
to over 600 instruments 
and computer 
peripherals 
that employ 
the use of the IEEE 488·1978 standard 
(General 
Purpose 
Interface 
Bus). The single-wide 
iSBX 
488 Multimodule 
board implements 
the complete 
IEEE 488·1978 Standard 
Digital 
Interface 
for Program· 


mabie 
Instrumentation 
by taking 
full 
advantage 
of Intel's 
VLSI technology. 
The iSBX 488 Multimodule 
bgard incorporates 
the 8291A GPIB Talker/Listener, 
8292 GPIB Controller 
and two 8293 GPIB Transceiver 
devices 
on a single 
low cost 
3.7" 
by 2.85" 
iSBX Multimodule 
board. The iSBX 488 board 
represents 
a 
significant 
step forward 
in joining 
microcomputers 
and instrumentation 
using industry 
standards 
such as 


the Multibus 
system 
bus, iSBX bus and IEEE 488·1978. The high performance 
iSBX 488 Multimodule 
board 
mounts easily on Intel iSBX bus compatible 
single board computers 
and provides 
functions 
which previously 
required 
a board eight times its size. 


The iSBX 488 board provides 
a simple 
programming 
interface 
to the user for easy reading, 
writing 
and 
monitoring 
of all GPIB functions. 
The intelligent 
interface 
provided 
by the iSBX 488 board minimizes 
the 


impact 
of the host processor 
bandwidth. 


The fOllowing 
are trademarks 
of tntel 
Corporation 
and may be used only 
10 describe 
Intel products. 
Intel, 
MULTI BUS, iRMX, iSeC, 
iSBX, MULTIMODUlE, 
les and iEBe, and the 


combination 
of MeS. 
ICE, IRMX, ISeC, iSBX. ieS or IEee, 
and a numencal 
suffix. 
Intel 
Corporation 
assumes 
no responsibility 
for the use of any Circuitry 
other 
than cIrcuitry 
embOdied 
in an Intel product. 
No other 
circuit 
patent 
licenses 
are implied. 
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The iSBX 488 Multimodule 
board is a single-wide 
iSBX 
bus 
compatible 
I/O expansion 
board 
that 
provides 
a complete 
implementation 
of the IEEE 
488-1978 
Standard 
Digital 
Interface 
for 
Pro- 


grammable 
Instrumentation. 
The iSBX 488 Multi- 
module 
board 
may be configured 
to be a GPIB 
controller, 
talker, 
listener 
or talkerllistener. 
The 
hardware 
implementation 
of the iSBX 488 board 
takes 
full 
advantage 
of Intel's 
VLSI capability 
by 
using 
the 
Intel 
8292 
GPIB 
controller, 
8291A 
talkerllistener 
and two (2) 8293 bus transceivers. 
All communication 
between 
the host iSBC board 
and the iSBX 488 Multimodule 
board is executed 
via the Intel standard 
iSBX connector. 
Many of the 
functions 
that previously 
were performed 
by user 
software 
have been incorporated 
into VLSI hard- 
ware for high 
performance 
and simple 
program- 
ming. 
Both the Intel 
8291A GPIB Talker/Listener 
device 
and 
the 
8292 
device 
can 
each 
com- 
municate 
independently 
with 
the host processor 
on the 
iSBC 
board 
depending 
on configuration. 
Communication 
from 
the 
host 
ISBC 
board 
to 
either device on the iSBX 488 board is flexible 
and 
may be either 
interrupt 
or poll driven depending 
on user requirements. 
Data transfers 
to or from 
the GPIB may be executed 
by the host processor's 
I/O Read and I/O Write 
commands 
or with 
DMA 


DEVICE 
I 
FUNCTION 
I 
I 
I 


i$BX'" 
I 


CONNECTOR: 


handshaking 
techniques 
for 
very 
high 
speed 
transfers. 


The 
Intel 
8291A device 
on the 
iSBX 488 Multi- 
module 
board 
handles 
all 
talkerllistener 
com- 
munications 
between 
the 
host 
iSBC 
processor 
board and the GPIB. Its capabilities 
include 
data 
transfer, 
bus handshake 
protocol, 
talker/listener 
addressing 
procedures, 
device 
clearing 
and trig- 
gering, 
service 
requests, 
and 
both 
serial 
and 
parallel 
polling 
schemes. 
In executing 
most 
pro- 
cedures 
the iSBX 488 board does not interrupt 
the 
microprocessor 
on 
the 
iSBC 
processor 
board 
unless a byte of data is waiting 
on input or a byte 
is sent to an empty output 
buffer, 
thus offloading 
the host CPU of GPIB overhead 
chores. 


SIMPLE 
PROGRAMMING 
INTERFACE 
- 
The 
GPIB talker/listener 
functions 
can be ea!Sily pro- 


grammed 
using 
the high 
level commands 
made 
available 
by 
the 
Intel 
8291A 
on 
the 
iSBX 
488 
Multimodule 
board. The 8291A device architecture 
includes 
eight 
registers 
for 
input 
and 
eight 
registers 
for output. 
One each of these 
read and 
write 
registers 
is used 
for direct 
data transfers. 
The remaining 
write registers 
are used by the pro- 


TRANSCEIVER 
& SUPPORT 
LOGIC 


ADDRESS, 


SELECT. 
MGMT. 


IORIW 


TALKER 
LISTENER 
ADDRESS 


grammer 
to control 
the various 
interface 
features 


of 
the 
Intel 
8291A 
device. 
The 
remaining 
read 


registers 
provide 
the user with a monitor 
of GPIB 


states, 
bus conditions 
and device 
status. 


SOFTWARE 
FUNCTIONS 
BUILT 
INTO 
VLSI 


HARDWARE 
- 
Additional 
features 
that 
have 


migrated 
from 
discrete 
logic 
and 
software 
into 


Intel 
VLSI 
include 
programmable 
data 
transfer 


rate and 
three 
addressing 
modes 
that 
allow 
the 


iSBX 
board to be addressed 
as either 
a major or a 


minor talker/listener 
with primary 
or secondary 
ad- 
dressing. 
The iSBX 488 Multimodule 
board can be 


programmatically 
configured 
into almost 
any bus 


talker, 
listener, 
or 
talkerllistener 
configuration. 
Writing 
software 
to control 
these 
and other 
iSBX 


488 board functions 
is simply 
a matter 
of reading 


or writing 
the control 
registers. 


iSBX 488™ 


Function 
Supported 
IEEE Subsets 


Source Handshake (SH) 
SHO,SH1 


Acceptor Handshake (AH) 
AHO,AH1 


Talker (T) 
TOthrough T8 


Extended Talker (TE) 
TEOthrough TE8 


Listener (L) 
LOthrough L4 


Extended Listener (LE) 
LEOthrough LE4 


Service Request (SR) 
SRO,SR1 


Remote Local (RL) 
RLO,RL1 


Parallel Poll (PP) 
PPO,PP1, PP2 


Device Clear (DC) 
DCOthrough DC2 


Device Trigger (DT) 
DTO,DT1 


Controller (C) 
COthrough C28 


1 For detailed information refer to IEEE Standard Digital Inter· 


face for Programmable 
Instrumentation 
published 
by The 


Institute of Electrical and Electronics Engineers, Inc., 1978. 


The 
GPIB 
controller 
functions 
supplied 
by the 


iSBX 
488 
board 
are provided 
by the 
Intel 
8292 


GPIB 
controller 
device. 
The 8292 is actually 
an 


Intel 8041 A eight 
bit microcomputer 
that has been 


preprogrammed 
to 
implement 
all 
IEEE 488-1978 


controller 
functions. 
The 
internal 
RAM 
in 
the 


8041A is used as a special 
purpose 
register 
bank 


for 
the 
8292 GPIB 
Controller. 
Just 
as with 
the 


8291A 
GPIB 
Talker/Listener 
device, 
these 


registers 
are used 
by the 
programmer 
to 
imple- 


ment 
controller 
monitor, 
read 
and 
write 
com- 


mands 
on the GPIB. 


When configured 
as a bus controller 
the iSBX 488 


board will respond 
to Service 
Requests 
(SRQ) and 


will 
issue 
Serial 
Polls. 
Parallel 
Polls 
are 
also 


issued 
to 
multiple 
GPIB 
instrument 
devices 
for 


receiving 
simultaneous 
responses. 
In 
applica- 


tions 
requiring 
multiple 
bus 
controllers, 
several 


iSBX 488 boards may each be configured 
as a con- 


troller 
and pass the active 
control 
amongst 
each 


other. 
An iSBX 488 board configured 
for a System 


Controller 
has 
the 
capability 
to 
send 
Remote 


Enable (REN) and Interface 
Clear (IFC) for initializ- 


ing the bus to a known 
state. 


The iSBX 488 Multimodule 
board interfaces 
to the 


GPIB 
using 
two 
Intel 
8293 
bidirectional 
trans- 


ceivers. 
The iSBX 488 board meets 
or exceeds 
all 


of 
the 
electrical 
specifications 
defined 
in 
IEEE 


488-1978 
including 
the 
required 
bus termination 


specifications. 
In addition, 
for direct 
connection 


to the GPIB, the iSBC 988 cable, 
a 26 conductor 


0.5 meter 
GPIB 
interface 
cable 
is also 
available 


from 
Intel. 
The cable 
is terminated 
with 
a 26-pin 


edge connector 
at the iSBX end and a 24-pin GPIB 


connector 
at the other. The cable 
is also supplied 


with 
shield 
lines 
for 
simple 
grounding 
in elec- 


trically 
noisy 
environments. 


The 
iSBX 
488 Multimodule 
board 
plugs 
directly 


onto the female 
iSBX connector 
available 
on many 


Intel iSBC boards. 
The Multimodule 
board is then 


secured 
at one additional 
point 
with 
nylon 
hard- 


ware (supplied) 
to insure 
the mechanical 
security 


of the assembly. 


Interface 
Information 


iSBXTM Bus - 
All signals 
TTL compatible 


26·pin 
edge 
connector 
- 
Electrical 
levels 
com- 
patible 
with 
IEEE 488-1978. 


Physical Characteristics 


Width 
- 
3.70 in (.94 em) 


Length 
- 
2.85 in (7.24 cm) 


Height 
- 
0.8 in (2.04 cm) 


Weight 
- 
3.1 oz (87.8 gm) 


GPIB Data Rate* 


300K bytes/see transfer rate with DMA host iSBC 
board 


SOKbytes/see transfer rate using programmed I/O 


730 nsec Data Accept Time 


• Data rates are iSBX board maximum. 
Data rates will vary 
and can be slower depending on host iSBe board and user 
software driver. 


DC power requirements 
- 


Vee= +SVdc 
±S% 


Ice = 600 milliamps 
maximum 


GPIB Electrical and 
Mechanical Specifications 


Conforms 
to IEEE 488-1978 standard 
electrical 


levels and mechanical 
connector 
standard when 


purchased with the iSBC 988 GPIB cable. 
. 


Environmental Characteristics 


Operating 
Temperature 
- 
0° to 60°C (32° to 
140°F) 


Relative 
Humidity 
- 
Up to 90% R.H. without con- 


densation. 


Reference Manual 


143154-001 - 
iSBX 488 GPIB Multimodule Board 


Hardware Reference Manual (not supplied). 


Part Number 


SBX 488 
SBC 988 


Description 


GPIB Multimodule 
O.Smeter GPIB cable for 
iSBX 488 Multimodule 
Board 


inter 


iSBX™ 352 
BIT SERIAL COMMUNICATIONS 
MUL TIMODULE™ 
BOARD 


• Provides 
an HOLC/SOLC half/full- 
duplex 
communications 
channel 
for 
iSBX™ bus compatible 
micro- 
computers 


• Supports 
RS232C (including 
modem 
support) 
or RS449/422A interface 


• Single + 5V when configured 
for 
RS449/422A interface 


• Software 
programmable 
baud rate 


generation 
up to 64K baud 
synchronous 
and 9_6K baud self- 
clocking 


• Supports 
synchronous 
or self-clocking 
NRZI point-to-point, 
multidrop 
and 


self-clocking 
NRZI SOLC loop data link 
interfaces 


The Intel iSBX 352 Bit Serial Communications 
MULTIMODULE 
board offers 
incremental 
on-board 
I/O ex- 
pansion 
support 
for ISO/CCITI's 
HDLC or IBM's SDLC communication. 
Plugging 
directly 
into any iSBX 
bus compatible 
host board, the iSBX 352 module 
provides 
one RS232C or RS449/422A programmable 
bit 
serial communications 
channel 
with software 
selectable 
eaud rates (up to 64K baud for half-duplex 
syn- 


chronous 
operations). 
Data link interfaces 
supported 
are:synchronous 
point-to-point, 
multidrop 
and SDLC 
loop. The phase lock loop feature 
provides 
NRZI self-clocking 
9.6K baud operation. 


The following 
are trademarks 
01 Inlel 
Corporation 
and may be used only 
to desCribe 
Intel 
products: 
Intel, 
CREDIT, 
Index, 
Insile, 
Inlellec, 
Library 
Manager, 
Megachassls, 


Micromap. 
MULTIBUS, 
PROMPT, 
UPt, ~Scope. 
Promware, 
MeS, ICE. iAMX, ,sac, ,sex, MUL TIMODULE 
and .CS. Intel Corporation 
assumes 
no responsibility 
for the use of any 
circuitry 
other 
than 
CirCUitry 
embodied 
in an lnlel 
product. 
No other 
Circuit 
patent 
licenses 
are Implied. 


© INTEL 
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Communications 
Interface 


The iSBX 352 module 
uses the Intel 8273 Program- 
mable 
HOLC/SOLC 
Protocol 
Controller. 
The iSBX 
352 
module 
provides 
one 
bit-serial 
communica- 


tions 
channel 
foriSBX 
bus compatible 
host micro- 
computers. 
(See 
Figure 
1.) An 
iSBC 
microcom- 


puter 
or 
MUL TIBUS-based 
application 
is 
easily 


connected 
to an HOLC/SOLC 
point-to-point, 
multi- 
drop, 
or an SOLC 
loop 
configuration. 


The High-Level 
Oata Link Control 
(HOLC) 
is the In- 
ternational 
Standards 
Organization 
(ISO) standard 
discipline 
used 
to implement 
X.25 packet 
switch- 


ing communications. 
The Synchronous 
Oata Link 


Control 
(SOLC) is an IBM communication 
protocol 


used 
to implement 
the System 
Network 
Architec- 
ture 
(SNA). 
Both 
protocols, 
HOLC 
and SOLC, 
are 
bit oriented, 
code 
independent, 
and 
support 
full- 
duplex 
operations. 


Data Link Interface 


The 
control 
lines, 
serial 
data 
lines 
and 
signal 


ground 
lines 
are brought 
out 
to the 
double 
edge 
connector 
of the iSBX 352 module 
and are config- 
urable 
for 
RS232C 
or 
RS449/422A 
interface 
(see 


Figure 
2). 


Addressing 
an iSBX 352 board 
by using 
a port ad- 


dress, 
the program 
performs 
the 8-bit data transfer 


required, 
using 
buffered 
or non-buffered 
transmit/ 


receive 
and abort 
sequences. 


Serial 
data transfer 
control 
is provided 
by the 8273 
controller 
of 
the 
iSBX 
352 
module 
which 
inter- 


faces 
the parallel 
iSBX bus to the serial 
channel. 


Ouring 
a transmit 
sequence, 
the iSBX 352 module 


accepts 
data and commands 
from 
the iSBX bus in- 
terface, 
translates 
and 
formats 
the 
data 
into 
HOLe/SOLC 
protocol 
formats, 
provides 
the proper 


RS232C 
or RS422A 
interface 
control 
signals, 
and 


passes 
data 
onto 
the serial 
channel. 
The 
receive 


operation 
is the inverse 
of the previous 
sequence. 


Data Link Configurations 


The supported 
data link configurations 
are shown 
in Table 
1. The following 
example 
configurations 


provide 
an overview 
and 
a figure 
for 
five 
typical 


data link configurations: 


Table 
1. iSBX™ 
352 Supported 
Configurations 


Connection 
Synchronous 
Asynchronous 


Modem 
Direct 
Modem· 
Direct 


point-to-point 
X 
X 
X 
X 


multidrop 
X 
X 
X 
X 


loop 
NA 
NA 
X 
X 


INTEL'!> ISBX'" 
352 


--- 
MUlTIMODUlE"· 


BOARD 


INTEL<!> ISBX"· 


.-:~ 
__ 
MUL TIMODULE"· 


) 
CONNECTOR 


Figure 
3 shows 
a synchronous 
point-to-point 
mode of operation 
for the iSBX 352 module. 
This 


RS232C example 
uses a modem for generation 
of 


the 
receive 
clock 
for 
coordination 
of 
the 
data 


transfer. 
The 
iSBX 
352 module 
generates 
the 


transmit 
synchronizing 
clock 
for 
synchronous 


transmission. 


T,C 
hD 


RTS 


iSBX'" 352 ers 
BOARD 
Rxe 
R,D 


DTR 


DSR 


R,C 
R,D 


RTS 
ers iSBX'" 352 
TxC 
BOARD 


T,D 


DSR 


DTR 


Figure 3. Synchronous 
Point·to·Point 
Modem 


Interface 
Configuration 
Example - 


RS232C 


The iSBX 352 module 
is used in an asynchronous 


mode 
interface 
when 
configured 
as 
shown 
in 


Figure 4. The point-to-point 
RS232C example 
uses 


the self-clocking 
mode interface 
for NRZI encod- 


ing/decoding 
of data. The digital 
phase lock loop 


allows 
operation 
of the 
interface 
in either 
half- 


duplex 
or 
full-duplex 
implementation 
with 
or 


without 
modems. 


RTS 


CTS 


iSBX'" 
352 
TxD 
BOARD 
RxD 


DTR 


DSR 


Figure 4. Self·Clocking 
Point·to·Point 
Modem 


Interface 
Configuration 
Example - 


RS232C 


SYNCHRONOUS 
MULTIDROP 


The 
iSBX 
352 MUL TIMOOULE 
is used 
in both 
a 
master and a slave mode in the RS449/422A 
exam- 


ple shown 
in Figure 5. This synchronous 
multidrop 
application 
is 
effective 
for 
high-speed 
data 


transfers 
between 
slave 
stations 
and 
a central 
master station. 


ASYNCHRONOUS 
SELF·CLOCKING 
MULTIDROP 


The iSBX 352 MULTIMOOULE 
example 
in Figure 6 
shows a master and multiple,slaves 
in a multidrop 


configuration. 
This 
self-clocking 
example 
uses 
the 8273 digital 
phase lock loop and NRZI data en- 


coding. 


SOLe Loop 


The SOLe self-clocking 
loop configuration 
shown 
in Figure 
7 permits 
longer 
networks 
since 
each 
secondary 
slave station 
is a repeater 
set in one-bit- 
delay mode. The data sent out by the primary 
sta- 
tion 
(the 
loop 
controller) 
are 
relayed 
bit-for-bit 
through 
each secondary 
station 
and finally 
back to 


the master 
station. 


TT 


so 


RT 
iSBX'" 
352 
BOARD 


RO 


TR 


1 


OM 
~ 


CONNECTOR 
CONNECTOR 
I 
J1 
J1 
RS 
OM 
SO 
TT 
RO 
RT 
RS 
OM 
SO 
TT 
RO 
RT 


iSBX·" 
352 
iSBX'" 
352 


BOARD 
BOARD 


NOTE: 
The last slave device in the system must contain termination resistors on all signal lines received by the slave board. 
The master device must contain resistors on all received signal lines. 


RO 


iSBX'" 
352 


BOARD 


Figure 6. Self·Clocking 
Multidrop 
Configuration 
Example 
- RS422A 


iSSX'" 
352 
RO 
SO 
iSBX'" 
352 


BOARD 
BOARD 


SO I-- 
--- 
RO 


12(9) 
815) 


RO 
SO 


iSBX'" 
352 


BOARD 


Figure 7. Self·Clocking 
SDLC Loop Network 


Configuration 
Example 


Data Size 


8 Bits 


Port 
Device 
Function 


Address 
Selected 
Performed 


8·bit 
16·bit 


XO 
XO 
Read Counter 0 
Write Counter 0 


X1 
X2 
8254-2 
Read Counter 1 
PIT 
Write Counter 1 


X2 
X4 
Read Counter 2 
Write Counter 2 


X3 
X6 
Write Control 


X4 
X8 
Read Status 
Write Command 


X5 
XA 
Read Result 
Write Parameter 


X6 
XC 
8273 
Read Transmit 
Interrupt 


HDLC/SDLC 
Write Reset 


X7 
XE 
CONTROLLER 
Read Receive Interrupt 


YO 
YO 
Read Receive Data 


Y4 
Y8 
Write Transmit 
Data 


NOTE: Refer to the Hardware Reference Manual for your host 
iSBCTM microcomputer 
to determine 
the upper digit 


(either X or Y) of the MULTIMODULETMport address. 


Interfaces 


iSBX™ 
BUS - 
All signals 
TIL 
compatible 


SERIAL 
RS232C 
SIGNALS 


CTS 
Clear 
to Send 


DSR 
Data Set Ready 


DTE TXC 
Transmit 
Clock 


DTR 
Data Terminal 
Ready 


FG 
Frame 
Ground 


RTS 
Request 
to Send 


RXC 
Receive 
Clock 


RXD 
Receive 
Data 


SG 
Signal 
Ground 


. TXD 
Transmit 
Data 


Baud 
8254·2 Divide 
Count 


Rate 
bits/see 
Synchronous 
Self·Clocking 


64K 
125 
TX Clock 
32X Clock 


56K 
143 
- 
- 


48K 
167 
- 
- 


19.2K 
417 
- 
- 


9.6K 
833 
833 
26 


4.8K 
1,667 
1,667 
52 


2.4K 
3,333 
3,333 
104 


1.2K 
6,667 
6,667 
208 


0.6K 
13,333 
13,333 
417 


0.3K 
26,667 
26,667 
833 


SERIAL 
RS449/422A 
SIGNALS 


CS 
Clear 
to Send 


DM 
Data Mode 


RC 
Receive 
Common 


RD 
Receive 
Data 


RS 
Request 
to Send 


RT 
Receive 
Timing 


SC 
Send Common 


SD 
Send 
Data 


SG 
Signal 
Ground 


TR 
Terminal 
Ready 


TT 
Terminal 
Timing 


OPERATING 
SPEEDS 


24 MHz on-board 
crystal 


8 MHz clocking 
of the 8254-2 PIT 


4 MHz clocking 
of the 8273 Device 


64K baud maximum 
for half-duplex 
operation 


48K 
baud 
for 
full·duplex 
operation 
issuing 
com· 


mands 
during 
transmit 
operations 


inter 


Configuration 
Mode' 
MUL TIMODULE™ 
Cable 
Connector 
Edge Connector 


RS232C 
OTE 
26-pin5, 3M-3462-0001 
3M3_3349/25 
25-pin7,3M-3482-1000 


RS232C 
OCE 
26-pin5, 3M-3462-0001 
3M3-3349/25 
25-pin7,3M-3483-1000 


RS449 
OTE 
40-pin6,3M-3464-0001 
3M'-3349/37 
37·pin'.3M-3502-1000 


RS449 
OCE 
40-pin6,3M-3464-0001 
3M4_3349/37 
37·pin',3M·3503-1000 


NOTES: 
1. Cable housing 3M-3485-4000 may be used with the connector. 
2. DTE - Data Terminal Equipment 
mode (male connector); 
DCE - Data Set Equipment 
mode (female connector). 


3. Cable is tapered at one end to fit the 3M-3462 connector. 
4. Cable is tapered to fit 3M-3464 connector. 
5. Pin 26 of the edge connector 
is not connected 
to the flat cable. 


6. Pins 38, 39, and 40 of the edge connector 
are not connected 
to the flat cable. 


7. May be used with the cable housing 3M-3485-1000. 


Interface 
Voltage 
Current 
Total 
(max) 
Power 
+ 5±0.25V 
595 mA 


RS 232C 
-12±0.6V 
30 mA 
3.8 watts 
+ 12± 0.6V 
30mA 


RS 449/422A 
+ 5± 0.25V 
775 mA 
4.1 watts 


Temperature 
- 
0 - 55·C, 
free moving 
air across 
base board and MULTIMODULE 
board 


Physical Characteristics 


Width 
- 
7.27 cm (2.85 inches) 


Length 
- 
9.40 cm (3.70 inches) 


Height 
- 
1.40 cm (0.56 inches) 


Weight 
- 
72 gm (2.53 ounces) 


Reference Manual (Not Supplied) 


143983 
- 
iSBX 
352 Bit 
Serial 
Communications 


MULTI MODULE 
Board 
Hardware 
Reference 


Manual. 


Reference 
manuals 
may be ordered 
from any Intel 
sales 
representative, 
distributor 
office 
or 
from 


Intel 
Literature 
Department, 
3065 
Bowers 
Ave., 


Santa Clara, California 
95051. 


Part Number 


SBX 352 


Description 


HDLC/SDLC 
Serial I/O 
MULTIMODULE 
Board 


iSBX 351 


SERIAL 
1/0 MULTIMODULE 
BOARD 


• Programmable synchronous/asynchro- 
nous communications 
channel with 


RS232C or RS449/422 interface 


• Software programmable baud rate 


generator 


• Two programmable 16·bit BCD or binary 


timers/event counters 


• Four jumper selectable interrupt 


request sources 


• Accessed as 110 port locations 


• Low power requirements 


• Single + 5V when configured for 


RS449/422 interface 


• iSBX bus on-board expansion elimi- 


nates MULTIBUS system bus latency 
and increases system throughput 


The Intel® iSBX 351 Serial I/O MUL TIMODULE 
board is a member of Intel's new line of iSBX bus compatible 


MUL TIMODULE 
products. 
The iSBX MUL TIMODULE 
board plugs directly 
into any iSBX bus compatible 


host board offering 
incremental 
on-board 
I/O expansion. 
The iSBX 351 module provides one RS232C or 


RS449/422 programmable 
synchronous/asynchronous 
communications 
channel with software selectable 


baud rates. Two general purpose programmable 
16-bit BCD or binary timers/event 
counters are available to 


the host board 
to generate 
accurate 
time 
intervals 
under 
software 
control. 
The iSBX board 
is closely 


coupled to the host board through 
the iSBX bus, and as such, offers maximum on-board 
performance 
and 


frees MUL T1BUS system traffic 
for other system resources. 
In addition, 
incremental 
power dissipation 
is 


minimum 
requiring 
only 3.0 watts (assumes 
RS232C interface). 


FUNCTIONAL 
DESCRIPTION 


Communications 
Interface 


The iSBX 351 module uses the Intel® 8251A Universal 
Synchronous/ 
Asynch ronous 
Receiver /Transm itter 
(USART) 
providing 
one programmable 
communi- 
cations 
channel. 
The USART 
can be programmed 
by the system 
software 
to individually 
select 
the 
desired 
asynchronous 
or synchronous 
serial data 
transmission 
technique 
(including 
IBM 
Bi-Sync). 
The mode of operation 
(i.e. synchronous 
or asyn- 
chronous), 
data format, 
control 
character 
format, 


parity, and baud .rate are all under program control. 
The 
8251A provides 
full 
duplex, 
double 
buffered 
transmit 
and receive 
capability. 
Parity, 
overrun, 


and framing 
error detection 
are all incorporated 
in 
the USART. The command 
lines, serial data lines, 


and signal ground 
lines are brought 
out to a double 
edge connector 
configurable 
for either an RS232C 
or RS449/422 
interface 
(see Figure 3). In addition, 


the iSBX 351 module is jumper configurable 
for either 
point-to-point 
or multidrop 
network 
connection. 


16-Bit Interval Timers 


The iSBX 351 module 
uses an Intel 8253 Program- 


mable 
Interval 
Timer 
(PIT) 
providing 
3 fully 
pro- 
grammable 
and independent 
BCD and binary 16-bit 
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CONNECTOR 
__ 


INTEL 
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MUL TIMODULE 
BOARD 
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~ 
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.::::::::::::. 
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interval timers. One timer is available to the system 
designer 
to generate 
baud 
rates for the USART 


under 
software 
control. 
Routing 
for the outputs 
from the other two counters 
is jumper selectable to 


the host board. In utilizing 
the iSBX 351 module, the 


systems 
designer 
simply 
configures, 
via software, 


each timer independently 
to meet system require- 
ments. Whenever a given baud rate or time delay is 
needed, 
software 
commands 
the programmable 


timers to select the desired function. 
The functions 


of the timers are shown in Table 1. The contents 
of 


each 
counter 
may 
be read 
at any time 
during 


system 
operation. 


Interrupt Request Lines 


Interrupt 
requests may originate from four sources. 


Two interrupt 
requests can be automatically 
gen- 


erated by the USART when a character 
is ready to 


be transferred 
to the host board (i.e. receive buffer 


is full) 
or a character 
has been transmitted 
(i.e. 


transmit 
buffer 
is empty). 
In addition, 
two jumper 


selectable 
requests 
can be generated 
by the pro- 
gra-mmable timers. 


The iSBX 351 module plugs directly 
into the female 
iSBX connector 
on the host board. The module 
is 


then 
secured 
at one additional 
point 
with 
nylon 


hardware 
to insure the mechanical 
security 
of the 


assembly 
(see Figures 
1 and 2). 


Function 
Oper8t1on 


Interrupt 
on 
When terminal count is reached, an interrupt 
terminal 
count 
request is generated. 
This function 
is useful 
for generation 
of real-time 
clocks. 


Programmable 
Output goes low upon receIpt of an external 


one~shot 
tngger edge and returns high when termmal 
count 
IS reached. This function is retrigger- 


able. 


Rate generator 
Divide by N counter. The output Will go low 
for one 
input 
clock 
cycle. 
and the period 
from one tow going pulse to the next IS N 
times the input clock period 


Square-wave 
Output 
wilt remain 
high until one-half 
the 


rate generator 
count has been completed, and go low for the 
other half of the count. 


Software 
Output 
remains 
high 
until 
software 
loads 
tnggered 
strobe 
count 
(N). 
N counts after count 
is loaded, 


output goes low for one input clock penod. 


Hardware 
Output 
goes 
low for one 
clock 
period 
N 
tnggered 
strobe 
counts after riSing edge counter trigger 
in- 


put 
The counter 
is retnggerable 


Event counter 
On a jumper selectable basis, the clock input 
becomes an input from the external system 
CPU may read the number of events occurr- 
ing after the counting 
"wmdow" 
has been 
enabled 
or an interrupt 
may be generated 
after N events occur 
In the system. 


1 
.40I 
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intel 


SPECIFICATIONS 


Word Size 
Data - 
8 bits 


1/0 
Chip 
Function 
Address 
Select 


XO. X2. X4. 
Write' 
Data 


or X6 
8251A 
Read: Data 


Xl. 
X3. X5. 
USART 
Write' Mode or Command 


or 
X7 
Read' Status 


Write: Counter 
0 


X8 or XC 
(Load Count 
+ N) 


Read' Counter 
0 


Write' Counter 
1 


X9 or XD 
(Load Count 
+ N) 


8253 
Read' Counter 
1 
PIT 
Write' Counter 
2 


XA 
or 
XE 
(Load Count 
+ N) 
Read: Counter 2 


XB or XF 
Write: Control 
Read: 
None 


NOTE: 
The first digit of each port 110 address is listed as "X" since it will 
change depending 
on the type of host iSBC microcomputer 
used. 
Refer to the Hardware 
Reference Manual for your host iSBC 
mIcrocomputer 
to determine 
the first digit of the I/O address. 


Access Time 
Read - 
250 nsec max 
Write - 
300 nsec max 
Note 
Actual transfer speed is dependent upon the cycle time of the 
host microcomputer. 


Synchronous 
- 
5 - 8-bit characters; 
internal char- 
acter synchronization; 
automatic 
sync insertion; 


even, odd or no parity 
generation/detection. 


Asynchronous 
- 
5 - 8-bit characters; 
break char- 
acter generation 
and detection; 
1, 1V2, or 2 stop 


bits; false start bit detection; 
even, odd or no parity 


gene ration/detect 
ion. 


8251 USART 
Baud Rale (Hz)' 


8253 PIT Frequency' 
(kHz, Software Selectable) 
Synchronous 
Asynchronous 


+ 
16 
+64 
307.2 
- 
19200 
4800 


153.6 
- 
9600 
2400 
76.8 
- 
4800 
1200 
38.4 
38400 
2400 
600 
19.2 
19200 
1200 
300 


9.6 
9600 
600 
150 


4.8 
4800 
300 
75 


2.4 
2400 
150 
- 


1.76 
1760 
110 
- 


NOTES: 1. Frequency selected by 110 writes of appropriate 
16-bit fre- 


quency factor to Baud Rate Register. 


2. Baud rates shown here are only a sample subset of possible 


software-programmable 
rates available. Any frequency from 


18.75 
Hz to 6144kHz 
may 
be generated 
utilizing 
on-board 


crystal oscillator 
and 16-bit Programmable 
Interval 
Timer 
(used here as frequency divider). 


Interval Timer ,nd 
Baud Rate Generator 


Input 
Frequency 
($electable): 


1.23 MHz ±0.1% 
(.813 lJSec period 
nominal) 


153.6 kHz ±0.1 % (6.5 lJSec period 
nominal) 


Rate Generator 
Real-Time 
Interrupt 


(Frequency) 
(Inlo",ol) 


Min. 
Max. 
Min. 
Max. 


Single 
18.75 Hz 
614.4 kHz 
1.63/1Sec 
53.3 
msec 
Timer' 


Single 
2.34 Hz 
76.8 kHz 
13.0/lSec 
426.7 
msec 
Timer2 


Dual 
TimerJ 
(Counters 
0.000286 Hz 
307.2 kHz 
3.26/1Sec 
58.25 
min 


o and 1 
in senes) 


Dual 
Timer" 
(Counters 
0סס oo358 
Hz 
38.4 kHz 
26.0/lSec 
7.77 hr. 


o and 1 
in series) 


NOTES: 1. Assuming 
1.23 mHz clock input. 


2. Assuming 
153.6 kHz clock input. 


3 Assuming Counter 0 has 1.23 mHz clock input. 


4. Assuming Counter 0 has 153.6 kHz clock input. 


Interrupts 


Interrupt 
requests 
may originate 
from the USART 


(2) or the programmable 
timer 
(2). 


Interfaces 


ISBX Bus - 
all signals TTL compatible. 


Serial - 
configurable 
for EIA Standards 
RS232C or 


RS449/422 


EIA Standard 
RS232C signals 
provided 


and supported: 


Clear to Send (CTS) 
Data Set Ready (DSR) 
Data Terminal 
Ready (DTR) 


Request to Send (RTS) 
Receive Clock 
(RXC) 


Receive Data (RXD) 
Transmit 
Clock 
(DTE TXC) 


Transmit 
Data (TXD) 


EIA Standard 
RS449/422 signals 
provided 


and supported: 
Clear to Send (CS) 
Data Mode 
(OM) 


Terminal 
Ready (TR) 


Request to Send (RS) 
Receive Timing 
(RT) 


Receive 
Data (RD) 


Terminal 
Timing 
(TT) 


Send Data (SO) 


Physical Characteristics 


Width 
- 
7.24 cm (2.85 inches) 


Length 
- 
9.40 cm (3.70 inches) 


Height" 
- 
2.04 cm (0.80 inches) 


iSBX 351 Board 


- 
2.86 cm (1.13 inches) 
iSBX 351 Board 
and Host 
Board 


Weight 
- 
51 grams 
(1.79 ounces) 


* (See Figure 2) 


Configuration 
Mode2 
MUL T1MODULE 
Edgo Conneclor 
Coble 
Connector 
8 


RS232C 
DTE 
26-pin'. 
3M-3462-0001 
3M'-3349/25 
25-pin'. 
3M-3482-1000 


RS232C 
DCE 
26-pin'. 
3M-3462-0001 
3M'-3349/25 
25-pin'. 
3M-3483-1000 


RS449 
DTE 
40-pin'. 
3M-3464-0001 
3M'-3349/37 
37-pin'.3M-3502-1000 


RS449 
DCE 
4o-pin'. 
3M-3464-0001 
3M'-3349/37 
37-pin'.3M-3503-1000 


NOTES: ,. Cable housmg 3M-3485-4000 may be used with the connector. 


2. DTE - 
Data Terminal mode (male connector), 
DCE - 
Data Set mode (female connector). 
3. Cable is tapered at one end to fit the 3M-3462 connector. 


4. Cable IS tapered to fit 3M-3464 connector. 


5. Pin 26 of the edge connector 
is not connected to the flat cable. 


6 
Pins 37, 39, and 40 of the edge connector 
are not connected to the flat cable. 


7 May be used with cable housing 3M-3485-1000. 


8. Connectors 
compatible 
with 
those 
listed 
may also 
be used. 


Electrical Characteristics 


DC Power 
Requirements 


Mode 
Voltage 
Amps 


, 
(Max.) 


RS232C 
+5V ±025V 
460 mA 


+12V 
±06V 
30 mA 


-12V 
±0.6V 
30 mA 


RS449/422 
+5V ±0.25V 
530 mA 


Environmental Characteristics 
Temperature 
- 
0 - 55°C, free moving air across the 


base board and MUL TIMODULE 
board. 


Reference Manual 
9803190-01 
- 
iSBX 351 Serial 110 MULTIMODULE 


Manual 
(NOT SUPPLIED) 
Reference Manuals may be ordered from any Intel 
sales representative, 
distributor 
office or from Intel 


Literature 
Department, 
3065 Bowers 
Ave., Santa 


Clara, California, 
95051. 


Part Number 
SBX 351 


Description 
Serial 
I/O MUL TIMODULE 
Board 


iSBX 350 


PARALLEL 
I/O MUL TIMODULE 
BOARD 


• 24 programmable I/O lines with sockets 


for interchangeable 
line drivers and 


terminators 


• Three jumper selectable interrupt 


request sources 


• iSBX bus on-board expansion elimi- 


nates MULTIBUS system bus latency 
and increases system throughput 


The Intel" iSBX 350 Parallel I/O MULTIMODULE Board is a member of Intel's new line of iSBX bus compatible 
MULTIMODULE products. The iSBX MULTIMODULE board plugs directly into any iSBX bus compatible host board 
offering incremental on·board expansion. The iSBX 350 module provides 24 programmable I/O lines with sockets for 
interchangeable line drivers and terminators. The iSBX board is closely coupled to the host board through the iSBX 
bus, and as such, offers maximum on-board performance and frees MULT1BUSsystem traffic lor other system 
resources. In addition, incremental power dissipation 
is minimal requiring only 1.6 watts (not including optional 
driver/terminators). 


Programmable 
Interface 


The iSBX 350 module uses an Intel'" 8255A-5 Program- 
mable Peripheral Interface (PPI)providing 24 parallel 1/0 
lines. The base·board system software is used to con- 
figure the 1/0 lines in any combination of unidirectional 
inputloutput and bidirectional ports indicated in Table 1. 
Therefore, the 1/0 interface may be customized to meet 
specific 
peripheral requirements. In order to take full 
advantage of the large number of possible 1/0 configura· 
tions, sockets are orovided for interchangeable 1/0 line 
drivers and terminators. Hence, the flexibility of the 1/0 
interface is further enhanced by the capability of select· 
ing the appropriate combination of optional line drivers 
and terminators to provide the required sink current, 
polarity, and driverltermination characteristics for each 
application. 
In addition, 
inverting 
bidirectional 
bus 
drivers (8226)are provided on sockets to allow conven- 
ient optional replacement to non·inverting drivers (8216). 
The 24 programmable 1/0 lines, signal ground, and + 5 


volt power Uumper configurable) are brought to a 50-pin 
edge connector that mates with flat, woven, or round 
cable. 


Interrupt 
Request Generation 


Interrupt 
requests 
may originate 
from three jumper 
selectable sources. Two interrupt requests can be auto- 
matically generated by the PPI when a byte of informa- 
tion is ready to be transferred to the base board CPU 
(i.e., input buffer is full) or a byte of information 
has 
been transferred to a peripheral device (i.e., output buf- 
fer is empty). A third interrupt 
source may originate 


directly from the user 1/0 interface (J1 connector). 


Installation 


The iSBX 350 module plugs directly into the female iSBX 
connector 
on the 
host board. The module 
is then 
secured at one additional point with nylon hardware to 
insure the mechanical security of the assembly (see 
Figure 1 and Figure 2). 
' 
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Mode 
of Operation. 


Unidirectional 


Port 
Lines 
Input 
, 
Output 
Bidirectional 
Control 
(qty) 


Unlatched 
Latched 
& 
Latched 
Latched 
& 
Strobed 
Strobed 


A 
8 
X 
X 
X 
X 
X 


B 
8 
X 
X 
X 
X 


C 
4 
X 
X 
. 
X1 


4 
X 
X 
X1 


NOTE: 


1. Part of port C must be used as a control 
port when either port A or port B are used as a latched and strobed input or a latched and strobed output port 
or port A is used as a bidirectional 
port. 


110Capacity 


24 programmable 
lines 
(see Table 
1) 


Word Size 


Data - 
8 Bits 


Access 
Time 


Read - 
250 ns max. 


Write 
- 
300 ns max. 


NOTE: 


Actual 
transfer 
speed 
is dependent 
upon the cycle 
time 
of the host 
microcomputer. 
8255A·5 
Ports 
iSBX 350 Address 


Port A 
XO or X4 


Port B 
Xl or X5 


Port C 
X2 or X6 


Control 
X3 or X7 


Reserved 
X8 to XF 


Interrupts 


Interrupt 
requests 
may 
originate 
from 
the 
program- 


mable 
peripheral 
interface 
(2) or the 
user 
specified 
I/O 
(1). 


NOTE: 


The first 
digit 
of each port 
1/0 address 
is listed 
as "X" 
since 
it will 


change dependent 
on the type of host iSeC microcomputer 
used. Refer 


to the Hardware Reference Manual for your host iSBC microcomputer 
to 
determine 
the first digit of the port address. 


Interfaces 


iSBX™ 
Bus - 
All signals 
TTL compatible 


Parallel 
I/O -: 
All signals 
TTL compatible 


No.of 
Cente'" 
Connector 
Vendor 
Interlece 
P.lraI 
(In.) 
Type 
Vendor 
P.rt 
No. 
Pin. 


Parallel 
1/0 
25150 
0.1 
Female 
3M 
341~1 
with 


Connector 
Ears 


Parallel 
1/0 
25150 
0.1 
Female, 
GTE 
6AD01251A1DD 


Connector 
Soldered 
Sylvania 


I/O Drivers - 
The following line drivers and terminators 


are all compatible 
with the I/O driver sockets on the 


iSBX 350. 


Driver 
Characteristic 
Sink Current 
(mA) 


7438 
I,oe 
46 


7437 
I 
48 


7432 
NI 
16 


7426 
I,oe 
16 


7408 
NI,Oe 
16 


7408 
NI 
16 


7403 
I,oe 
16 


7400 
I 
16 


Note: 


I = Inverting, NI = Non-Inverting, 
OC;: Open Collector 


Port 1 has 25 mA totem pole drivers and 1 k{l termi- 
nators. 


I/O Terminators - 
220nl330{l divider or 1 k{l pull up. 


220\l/330n 
(iSBC 901 OPTION) 


22011 


+5V...L===~=;=~--o 


1 kP.(iSBC 902 OPTION) 
lk!! 
+5V 
-----I'W~. 
--------0 


Physical 
Characteristics 


Width - 
7.24 cm (2.85 in.) 


Length - 
9.40 cm (3.70 in.) 


Height' 
- 
2.04 cm (0.80 in.) iSBX 350 Board 


- 
2.86 cm (1.13 in.) iSBX 350 Board + Host 
Board 
Weight - 
51 gm (1.79 oz) 


Electrical 
Characteristics 


DC Power Requirements 


Power Requirement 
Configuration 


+ 5V@ 
320 mA 
Sockets 
XU3, XU4, XU5, and XU6 empty 
(as 


shipped). 


+ 5V@ 
500 mA 
Sockets 
XU3, XU4, XU5, and XU6 contain 


7438 buffers. 


+ 5V@620mA 
Sockets 
XU3, XU4, XU5, and XU6 contain 


iSBC 901 termination 
devices. 


Environmental 


Operating Temperature - 
O·C to 55·C 


Reference 
Manual 


9803191·01 - 
iSBX 350 Parallel I/O MULTIMODULE 


Manual (NOT SUPPLIED) 


Reference Manuals may be ordered from any Intel sales 
representative, distributor office or from Intel Literature 
Department, 3065 Bowers Ave., Santa Clara, California 
95051. 


Part Number 


SBX 350 
Description 


Parallel I/O MULTIMODULE 
Board 


APPLICATION 
NOTE 


INTRODUCTION 


Intel's 
single 
board 
computers 
and 
the MUL TIBUS™ 


system 
bus have become 
de facto 
industry 
standards 
in 


the microcomputer 
board 
market. 
The speed and capa- 
bility of the bus coupled 
with the functionality 
and per- 


formance 
of the boards 
have been used to solve a large 
number 
of problems. 
iSBC products 
are in applications 
ranging 
from 
simple 
single board 
relay replacement 
to 


sophisticated 
multi-board 
business 
systems 
supporting 
large 
hard 
disk 
files. However, 
even with the range 
of 


functionality 
provided 
by standard 
iSBCs 
and 
expan- 


sion 
boards, 
designers 
have 
felt 
the 
need 
to 
design 


custom 
MUL TIBUS-compatible 
boards 
to fit their 
ap- 
plication. 
Until 
the introduction 
of the iSBX concept, 


these 
custom 
boards 
had 
to be implemented 
using 
a 


separate 
MUL TIBUS 
form factor 
board. 


Intel has recently 
introduced 
a new line of board 
prod- 
ucts 
and 
a new 
bus 
which 
are 
destined 
to 
become 


another 
industry 
standard 
because 
of the niche they fill. 


The new iSBX MUL TIMODULE 
boards 
are designed 


to extend 
the 
functional 
capabilities 
of 
single 
board 


computers 
at a much 
lower 
cost than 
previously 
possi- 


ble. iSBX MUL TIMODULE 
boards 
are supported 
by a 
new 
bus - 
the 
iSBX 
bus, 
which 
allows 
the MUL TI- 


MODULE 
boards 
to be added 
directly 
to the on-board 


microprocessor 
bus. 
iSBX 
MUL TIMODULE 
boards 
are from 10 to 20 square 
inches in size, therefore 
permit- 


ting small 
modular 
increments 
to a single 
board 
com- 
puter's 
capabilities. 


System 
designers 
now 
have 
the 
capabilities 
of 
using 


either 
standard 
iSBCs 
or 
iSBX 
MUL TIMODULE 
boards, 
or designing 
custom 
MUL TIBUS 
compatible 
or 


iSBX 
MUL TIMODULE 
boards. 
Cost-effective 
solu- 


tions are easily realized 
because 
of this added 
flexibility. 


This 
application 
note 
discusses 
the 
iSBX 
MUL TI- 


MODULE 
concept, 
currently 
available 
MULTIMOD- 


ULE boards 
and the iSBCs which support 
these boards. 


The 
iSBX 
bus 
interface 
specifications 
are 
discussed 


next, 
followed 
by consideration 
for 
designing 
custom 


iSBX MUL TIMODULE 
boards. 
A specific 
design 
ex- 


ample 
using 
an Intel® 8279 Programmable 
Keyboard! 


Display 
Controller 
is presented. 


The objective 
of the note 
is to introduce 
the reader 
to 


the 
iSBX 
MUL TIMODULE 
concept 
for 
expanding 


iSBC functionality 
and to illustrate 
how a designer 
can 


effectively 
use 
this 
concept 
with 
either 
standard 
or 


custom 
iSBX boards. 


References 
to further 
documentation 
on the iSBX bus, 


specific 
iSBX MULTIMODULE 
boards 
and iSBC host 
boards 
currently 
available 
may be found 
in the Related 
Intel 
Publications 
section 
in the 
front 
overleaf 
of this 
application 
note. 


iSBX™ MULTIMODULE™ BOARD 
CONCEPT 


The iSBX MUL TIMODULE 
board 
concept 
was devel- 
oped 
to provide 
the 
users 
of Intel 
single 
board 
com- 
puters 
(iSBCs) 
with a convenient 
method 
to increment- 


ally expand 
the I/O 
or the computing 
capabilities 
of a 


single board 
computer. 
This expansion 
is done through 


the use of a new interface 
called the iSBX bus interface. 


This interface 
gives the user the capability 
of adding 
I/O 


mapped 
functions 
directly 
onto 
the microprocessor 
bus 
via plug-in 
modules 
that connect 
to the iSBC board 
by 


means 
of a special iSBX connector. 
With the use of this 


new bus interface, 
it is now possible 
to expand 
or add 


new 
features 
to your 
iSBC 
system 
without 
incurring 


large costs and long engineering 
development 
times. 


There 
are a number 
of unique 
advantages 
to using the 


iSBX 
bus 
interface 
for 
system 
expansion 
rather 
than 
adding 
a separate 
expansion 
board 
to 
your 
system. 


First, when expansion 
is required, 
the user needs only to 


buy what 
is required 
for the application. 
Second, 
it is 


now possible 
to return 
to one board 
solutions 
for small 
systems. 
One board 
solutions 
eliminate 
the need for ex- 


pensive backplanes 
and cardcages. 
Next, the iSBX inter- 


face 
connects 
directly 
to the 
microprocessor 
or 
local 


bus, 
as opposed 
to interfacing 
to the MUL TIBUS 
sys- 


tem 
bus, 
therefore 
I/O 
expansion 
does 
not 
require 
system 
bus cycles. 
To the CPU, 
the iSBX board 
looks 


like any other 
on-board 
I/O 
device (Figure 
I). Address 


decode 
logic 
exists 
on the 
iSBC 
host 
board 
for 
each 


iSBX connector 
on the host board. 


iSBC'" 


SINGLE 
BOARD 
COMPUTER 


Figure 1. iSBCTM Host Board Block Diagram 


Third, 
if there 
is no iSBC or MUL TIBUS 
compatible 


expansion 
board 
available 
to fit the needs of your appli- 


cation 
or if the expansion 
boards 
available 
offer 
more 
capability 
than 
required, 
then 
it is possible 
to design 
a 


custom 
iSBX MUL TIMODULE 
board. 
Custom 
iSBX 


boards 
offer 
several 
advantages 
over 
custom 
MUL Tl- 


BUS boards: 
they require 
less board 
real estate (10 or 20 


square 
inches versus 81 square 
inches) and less engineer- 
ing design 
time; 
consequently, 
they 
cost 
considerably 
less to 
implement. 
Additional 
capability 
is therefore 
achieved 
with maximum 
productivity. 


Currently 
available 
Intel 
iSBX 
MUL TIMODULE 
Boards 
include: 


I) iSBX 
350 Parallel 
I/O 
MUL T1MODULE 
board 
which 
contains 
24 programmable 
I/O 
lines with 
sockets 
for line drivers 
and terminators. 


2) iSBX 
351 
Serial 
I/O 
MULTIMODULE 
board 


containing 
one 
RS232 
or 
RS449/422 
program- 
mable 
synchronous/asynchronous 
communica- 
tions channel 
and two timers. 


3) iSBX 
331 Fixed/Floating 
Point 
Math 
MUL TI- 
MODULE 
board 
which 
permits 
fixed or floating 
point 
mathematics 
via the Intel 8231 device. 


4) iSBX 332 Floating 
Point 
Math 
MUL TIMODULE 
board 
which 
permits 
floating 
point 
mathematics 
using the Intel and proposed 
IEEE 
floating 
point 


standards 
via an Intel 8232 device. 


With 
these 
iSBX 
MUL TIMODULE 
boards 
and 
other 


soon-to-be-announced 
boards, 
the capability 
now exists 
to economically 
tailor 
a single 
board 
computer 
to the 
application 
using off-the-shelf 
products. 


iSBX™ MULTIMODULE™ 
SYSTEM 
INTERFACE 


This 
section 
begins 
by describing 
the basic system 
ele- 
ments used in an iSBX MUL TIMODULE 
interface 
con- 


figuration 
and then defines 
the interface 
signals used for 
the communication 
between 
these elements. 
The specifi- 
cations 
contained 
in this application 
note 
are included 
for descriptive 
and tutorial 
purposes 
only. The ultimate 


source 
for this information 
is the iSBX Bus Specifica- 
tion 
which 
is referenced 
in the 
front 
overleaf 
of this 


note. 


The host board 
provides 
an electrical 
and mechanical 
in- 
terface 
for the iSBX expansion 
module. 
The host board 
is the master 
of the communications 
between 
the host 
and iSBX board, 
it controls 
the address 
and command 


signals. 


A new generation 
of iSBX bus compatible 
host 
boards 
are evolving. 
The first board 
available 
from 
Intel is the 
iSBC 80/IOB 
Single Board 
Computer. 
The 80/IOB 
con- 


tains 
an 8080A CPU 
operating 
at 2 MHz, 
I K bytes of 
RAM 
with wckets 
available 
for expansion 
to 4K bytes 


of RAM, 
sockets 
for up to 16K bytes 
of EPROM, 
24 
parallel 
I/O 
lines, 
a programmable 
synchronous/asyn- 


chronous 
communications 
interface 
and 
a fixed 
1.04 
msec timer. 
The 80/IOB 
has one iSBX connector, 
per- 
mittmg 
the use of an iSBX MUL TlMODULE 
board. 


The 
second 
iSBC 
board 
available 
supporting 
iSBX 
boards 
is the iSBC 80124 Single 
Board 
Computer. 
The 
80124 board, 
which 
supports 
two iSBX MULTIMOD- 
ULE 
boards, 
contains 
an 8085A-2 
CPU 
operationg 
at 
4.8 or 2.4 MHz, 
4K bytes 
of RAM, 
sockets 
for up to 
32K by,tes of EPROM, 
48 parallel 
I/O lines, a program- 


mable 
synchronous/asynchronous 
communications 
in- 
terface, 
three 
programmable 
interval 
timers 
and a pro- 
grammable 
interrupt 
controller. 
Further 
RAM 
expan- 
sion on the 80124 board 
is accomplished 
by the addition 
of an iSBC 301 4K byte RAM MUL T1MODULE 
board 
which expands 
the RAM by an additional 
4K bytes for a 
total 
of 
8K bytes. 
The 
iSBC 
301 
MUL TIMODULE 
board 
is not iSBX bus compatible; 
it is attached 
via pins 


and sockets 
in the RAM section 
of the host board. 


iSBX™ MULTIMODULE™ 
Boards 


The iSBX MUL T1MODULE 
boards 
communicate 
with 
the host boards 
via the iSBX bus interface. 
These iSBX 
boards 
are I/O 
mapped 
through 
pre-defined 
select lines 


to 
specific 
port 
addresses. 
The 
iSBX 
bus 
currently 


defines 
an 8-bit data 
path 
compatible 
with both 
8 and 
16-bit 
future 
iSBC 
host 
boards. 
Examples 
of possible 


iSBX expansion 
boards 
include a floppy disk controller, 
a 
cass~tte 
interface, 
analog-to-digital 
converter 
or 
digital-to-analog 
converter 
boards, 
an interface 
to the 
IEEE 
488 Bus and 
a video 
graphics 
display 
interface 


board. 


There 
are two standard 
sizes of iSBX boards: 
a single- 
wide 
board 
measuring 
7.24 
by 9.40 
cm (2.85 
by 3.70 
inches) 
and 
a double-wide 
board 
measuring 
7.24 
by 
19.05 
cm 
(2.85 
by 7.50 
inches). 
The 
iSBX 
MULTI- 
MODULE 
boards 
mount 
onto 
any 
microcomputer 
board 
containing 
an 
iSBX 
connector 
and 
mounting 
hole. 
The 
iSBX 
boards 
physically 
plug 
into 
the iSBX 
connector 
on 
the 
host 
board 
and 
are 
secured 
with 
a 


nylon 
stand-off 
and 
screws. 
The 
mounting 
hardware 


supplied 
as part 
of the iSBX board 
includes: 


I) One nylon 
spacer, 
1/2" 
threaded 


2) Two nylon 
screws, 
1/4" 
6-32 


3) One 
36-pin 
connector, 
factory-installed 
onto 
the 
iSBX 
module. 
(These 
may 
also be purchased 
from 
Intel.) 


The interconnection 
between 
the host 
board 
and 
iSBX 
board, 
as well as the mounting 
clearances, 
may be seen 
in Figures 
2 and 3.. 


The 
iSBX 
board, 
when 
installed 
onto 
a 
host 


board, 
occupies 
an additional 
card slot adjacent 
to 
the 
base 
board 
in an 
iSBC 
604/614 
Cardcage. 


However, 
the base 
board 
may be inserted 
in the 


top card 
slot of the cardcage. 
If this is done, 
no 


additional 
slots are required. 


/HOSTBOARD 


INTEL iSBX" 
C;:?/:"". 
_MULTIMODULE'· 
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iSBX™ Connector 


The iSBX interface 
connector 
is a 36-pin 
custom 
made 


connector 
that 
was designed 
by-Intel 
especially 
for this 


interface. 
The connector 
is plastic 
with gold plated 
con- 


tact pins for maximum 
reliability. 
The connector 
for the 
iSBX interface 
was designed 
for high reliability 
and dur- 


ability. 
The connection 
between 
the host board 
and the 


iSBX 
MUL TIMODULE 
board 
was extensively 
tested 


for vibration, 
shock, 
humidity, 
and temperature 
to in- 
sure that the connection 
is rugged 
enough 
to be used in 


severe environments. 
This connection 
was tested 
for the 


following 
environment: 


Sweeping 
from 
10 Hz to 55 Hz and back 
to 
10 Hz at a distance 
of 0.010 
inches 


peak-to-peak, 
lasting 
15 minutes 
in each 


of the three 
planes. 


30g's 
of force 
for an 
Il-msec 
duration, 


three 
times 
in three 
planes, 
both 
sides 


(total 
of 18 drops). 


90010 maximum 
relative 
(no 
condensa- 
tion). 


Temperature: 
0 to 
55°C 
(32-131°F) 
free 
moving 
air 


across 
the 
base 
board 
and 
the 
iSBX 
MUL TIMODULE 
board. 


Further 
information 
on the reliability 
testing 
that 
was 


done on this inter-connection, 
or reliability 
information 


on the 
iSBX 
MUL TIMODULE 
boards 
in general, 
is 
contained 
in the Reliability 
Report, 
RR-29, 
"Intel 
iSBX 


MUL TIMODULE 
Boards 
and 
iSBC 
801 lOB 
Single 


Board 
Computer," 
listed in the overleaf 
of this note. 


The male half of this connector 
is available 
from Intel in 


the form of the iSBX 960-5 package 
which contains 
five 
of the connectors. 


iSBX™ Bus Interface Signals 


The 
iSBX 
bus 
interface 
signals 
are 
grouped 
into 
six 


basic groups, 
or classes, 
according 
to the functions 
per- 


formed 
relative 
to the interface: 


These 
signals 
are: 


CONTROL 
LINES 


ADDRESS 
LINES 


DATA 
LINES 
INTERRUPT 
LINES 
OPTIONAL 
LINES 


POWER 
LINES 


Many 
of the 
signals 
on the iSBX 
bus are 
active-low, 


meaning 
a low level on a control 
signal of the bus indi- 


cates a logic" 
I" 
value, 
while a low level on an address 
or data 
signal of the bus represents 
a logic "0" 
value. 


In this application 
note, 
an active-low 
signal 
will 
be 
designated 
by 
placing 
a 
slash 
(I) 
after 
the 


mnemonic 
for the signal. 


Appendix 
A contains 
a pin assignment 
list of the follow- 
ing signals: 


The following 
signals 
are classified 
as control 
lines: 


I) COMMANDS 
- 
lORDI, 
IOWRTI 


2) DMA 
- 
DMRQT, 
MDACK/, 
TDMA 
3) INITIALIZE 
- 
RESET 
4) CLOCK 
- 
MCLK 
5) SYSTEM 
CONTROL 
- 
MWAIT/, 
MPSTI 


Command 
Lines (I/O READ, I/O WRITE) 


The command 
lines are active-low 
signals which control 
the communication 
link between 
the host board 
and the 
iSBX 
board. 
An active 
command 
line conditioned 
by 
chip select indicates 
to the iSBX board 
that the address 


lines are valid and the iSBX board 
should 
perform 
the 
specified 
operation. 


DMA Lines (MDROT, 
MDACK/, 
TDMA) 


The DMA lines control 
the communication 
link between 
the DMA device on the host board 
and the iSBX mod- 
ule. 
DMRQT 
is an active-high 
output 
signal 
from 
the 
iSBX board 
to the host board's 
DMA device requesting 
a DMA cycle. MDACKI 
is an active-low 
input 
signal to 
the iSBX board 
from 
the host 
board 
DMA 
device 
ac- 
knowledging 
that 
the 
requested 
DMA 
cycle 
has 
been 
granted. 
TDMA 
is used by the iSBC board 
to terminate 
DMA 
activity. 
The use of the DMA 
lines is optional 
as 
not all host boards 
will provide 
DMA 
channels 
nor will 
all iSBX boards 
be capable 
of supporting 
them. 


Initialize 
Line (RESET) 


This active-high 
input 
line to the iSBX board 
is gener- 
ated 
by the host 
board 
to put 
the iSBX 
board 
into 
a 
known 
internal 
state. 


Clock 
Line (MClK) 


This input line to the iSBX board 
is a timing signal. 
The 
clock 
frequency 
is 10 MHz. ( + 0070, - 10%), 
and 
the 
clock is asynclironous 
with respect 
to all other iSBX bus 
signals. 


System 
Control 
Lines (MWAIT/, 
MPSn 


These 
output 
signals 
from 
the iSBX board 
control 
the 
state 
of the system. 
Active 
MW AIT I (active-low) 
will 


put the CPU on the host board 
into a wait state, 
provid- 


ing additional 
time 
for the iSBX board 
to perform 
the 


requested 
operation. 
MPST I is an 
active-low 
signal 


(usually 
tied 
to signal 
ground) 
that 
informs 
the 
host 
board 
I/O 
decode 
logic that 
an iSBX module 
has been 


installed. 


ADDRESS 
AND 
CHIP 
SELECT 
LINES 


The 
address 
and 
chip 
select 
lines are made 
up of the 


following 
signals: 


1) ADDRESS 
LINES 
- 
MAO, MAl, 
MA2 


2) CHIP 
SELECT 
LINES 
- 
MCSO/, 
MCSI/ 


Address 
Lines 
(MAO, MA1, 
MA2) 


These 
active-high 
input 
lines 
to the 
iSBX 
boards 
are 


generally 
the least three 
significant 
bits of the I/O 
ad- 


dresses. 
In conjunction 
with 
the 
command 
and 
chip 


select lines, they establish 
the I/O port address 
being ac- 


cessed. 


Chip 
Select 
Lines 
(MCSO/, 
MCS1/) 


These 
active-low 
input 
lines to the iSBX board 
are the 


result of the host board 
I/O decode 
logic. When 
active, 
the MCSI 
lines condition 
the 1/0 
command 
signals and 


thus 
enable 
communication 
between 
the 
iSBX 
board 


and the host 
board. 


DATA 
LINES 
(MDO-MD7) 


There 
are 
eight 
bidirectional 
data 
lines. 
These 
active- 


high lines are used to transmit 
or receive information 
to 


or from the iSBX ports. 
MOO is the least significant 
bit. 


INTERRUPT 
LINES 
(MINTRO, 
MINTR1) 


These active-high 
output 
lines from the iSBX board 
are 


used to make interrupt 
requests 
to the host board. 
These 


lines are jumper 
enabled 
and disabled 
on the host board 


via wire wrap 
posts. 


These 
two signals 
are reserved 
lines that 
are corinected 


to wire wrap posts on both the host board 
and the iSBX 


MULTIMODULE 
board. 
They are for unique 
require- 


ments 
where 
a user needs a host board 
or MUL TIBUS 


bus signal on the iSBX module. 


All host boards 
provide 
+ 5 volts as well as ± 12 volts to 


the 
iSBX 
MULTIMODULE 
board 
along 
with 
signal 


ground. 
All power 
supply 
voltages 
are 
± 5010. Table 
I 


gives the power supply specifications 
for the iSBX inter- 


face. 


Minimum 
Nominal 
Maximum 
Maximum 
(volts) 
(volts) 
(volts) 
(current)· 


+4.75 
+5.0 
+5.25 
3.0A 


+11.4 
+12 
+ 12.6 
LOA 


-12.6 
-12 
-11.4 
LOA 


- 
GND 
- 
6.0A 


This section 
of the application 
note focuses 
on the iSBX 


interface 
and design 
considerations 
related 
to interfac- 


ing with the iSBX bus. 
It discusses 
the way the major 
operations 
like READ, 
WRITE, 
and DMA 
work, 
and 
the timing diagrams 
associated 
with each. There is also a 


discussion 
on other 
considerations 
for designing 
with 


the iSBX bus. 


Bus Timing 


The AC timing specifications 
for the iSBX bus interface 


can be found 
in Appendix 
B of this application 
note. 
It 


should 
be emphasized 
that the interface 
timing 
between 


the host board 
and the iSBX MUL TIMODULE 
board 
is 
very critical. 
This is largely due to the fact that the iSBX 


board 
is attached 
directly 
to the microprocessor 
bus. 
If 


the timing 
specifications 
are not met, unpredictable 
and 


possibly 
intermittent 
operation 
of the host 
board 
may 


result. 


Command 
Operations 


The command 
lines (lORDI, 
10WRT) 
are driven 
from 


the host board 
by three-state 
drivers 
with pull-up 
resis- 


tors or standard 
TTL totem-pole 
drivers. 
These lines in- 


dicate 
to the iSBX board 
that action 
is being requested. 


There 
are two types 
of operations 
for each 
command 


line 
and 
it is the 
iSBX 
board 
that 
determines 
which 


operation 
is to be performed. 


READ OPERATIONS 
(lORD/) 


Two different 
types of read operations 
are possible. 
The 


first type of read is called 
a full speed I/O 
READ. 
The 


host 
board 
generates 
a valid 
I/O 
address 
(MAO-MA2) 


and a valid chip select signal (MCSI/) 
which is then sent 


to the iSBX board; 
after 
the set-up 
times 
are met, 
the 


host 
board 
activates 
the'IORDI 
line. At this time, 
the 


iSBX 
board 
must 
generate 
valid 
data 
from 
the 
ad- 
dressed 
I/O 
port 
in less than 
250 ns. The 
host 
board 


then reads 
the data 
and removes 
the READ 
command, 


address 
and chip selects. 
These 
are shown 
in the timing 


diagram 
for this operation 
(Figure 
4). The second 
type 


of read 
operation 
is called 
an I/O 
READ 
with 
Wait. 


This READ 
is used by iSBX boards 
that cannot 
perform 


a full speed 
read 
operation. 
Under 
this operation 
the 


host board generates the valid address and chip select 
signals, as in the.full speed read. But this time the iSBX 
board will activate the MWAITI signal, which in turn 
removes the READY input to the CPU, putting it into a 
Wait 
state. 
The CPU, 
however, 
first activates 
the 
IORDI signal before going into the Wait state. After 
valid data is placed on the iSBX data bus by the iSBX 
board, the iSBX board will remove the MWAITI signal. 
The host board will then read the data and remove the 
command, 
address, 
and chip select lines. This I/O 


READ with Wait operation is shown in Figure 5. 


WRITE 
OPERATIONS 
(IOWRT/) 
There are also two types of write operations possible: 
the type performed 
is again determined by the iSBX 
board. In the full speed I/O WRITE operation, the host 
board generates a valid I/O address and chip select and 
then activates the IOWRT I line after the necessary set- 
up times are met. The IOWRT/line, 
after being acti- 


vated, will remain active for 300 ns and the data will be 
valid for 250 ns before the IOWRTI command is re- 


moved. The host board will then remove the data, ad- 
dress, and chip select lines after the hold times are met, 
as shown in the timing diagram of this operation (Figure 
6). 


This se~ond write operation 
is the I/O WRITE with 
Wait operation. 
This WRITE 
is used by the iSBX 


boards that cannot write into an I/O port with the full 
speed 
write 
specifications. 
The 
host 
board 
again 
generates valid address and chip select signals as in the 
full speed write operation. However, this time the iSBX 
board generates the MWAITI signal based on address 
information 
(chip select and MAO-MAI). The activa- 
tion of MWAITI causes the removal of READY to the 
CPU, thus causing the CPU to go into a Wait state. The 
iSBX board removes the MWAITI 
signal (allowing the 


CPU to leave its Wait state) when it has satisfied the 
WRITE 
pulse width requirements. 
At this time the 


board removes the WRITE command, followed by the 
data, address, and chip select lines. This I/O WRITE 
with Wait operation can be seen in Figure 7. 


iSBX™ Addressing 


The 
iSBX 
boards 
are 
addressed 
by 
the 
host 
board 


through 
the 
use of the address 
lines 
MAO, MAL and 


MA2, and the chip select lines MCSO/ and MCSI/. 
The 


host board 
decodes 
the I/O addresses 
and in turn gener- 


ates the chip selects for the iSBX boards. 
In an 8-bit sys- 


tem the host 
board 
decodes 
the high order 
13 address 


bits 
and 
generates 
the 
appropriate 
chip 
select 
corre- 


sponding 
to those 
address 
bits. The low order 
three ad- 


dress bits are passed 
to the iSBX board 
via MAO-MA2. 
Thus, 
a host 
board 
reserves 
two 
blocks 
of eight 
I/O 
ports 
for each iSBX connector. 
There can be as many as 


three 
iSBX connectors 
per host board, 
therefore 
a total 


of 48 addresses 
or six blocks of eight I/O ports 
that can 


be reserved 
for the iSBX boards. 
Table 
2 contains 
a list 


of the I/O addresses 
and their corresponding 
host board 


iSBX port 
assignments 
of the iSBC 
80/IOB 
and 
iSBC 


80124 host 
boards. 


iSBX™ Connector 
Chip Select 
iSBX™ Port 


Number 
Addresses 


iSBC 80/lOB 
MCSOI 
FO-F7 


Connector 
MCS\I 
F8-FF 


iSBC 80124 First 
MCSOI 
FO-F7 


Connector 
MCSII 
F8-FF 


iSBC 80/24 Second 
MCSOI 
CO-C7 


Connector 
MCS\I 
C8-CF 


Considerations 
for iSBXTM Bus Interfacing 


When 
designing 
with the iSBX interface 
it is important 


to note 
that 
the iSBX bus is not buffered 
on the host 


board. 
Since 
there 
is no 
isolation 
between 
the 
iSBX 


board 
and the host board 
CPU bus, a short between 
sig- 
nallines 
and power or ground 
could have a direct effect 


on the CPU or the drivers and receivers associated with 
the CPU on the host board. This must be taken into 
consideration, especially when designing and debugging 
any custom designed iSBX MULTIMODULE board. It 
is usually during the development states of a product 
that these types of problems occur. One advantage to 
not buffering the iSBX bus is increased speed of data 
and command transfers. Applications requiring buffer- 
ing may add the buffers on the iSBX board. A second 
advantage to not buffering is the saving of parts costs, 
board real estate and development time for the host 
board. Another consideration when designing with the 
iSBX interface is, if the application to be designed re- 
quires high throughput, 
like a floppy disk controller or 
a CRT controller, 
the designer may consider putting 


some type intelligent control of buffer RAM onto the 
iSBX board. By doing this, the transfer information can 
be stored in this buffer and the throughput of the system 
increased. 


Loading 
requirements 
for the iSBX bus have been 
broken up into two basic categories, output specifica- 
tions and input specifications, which can be viewed in 


Tables 3 and 4. The output specifications are the re- 
quirements on the output drivers of the iSBX board and 
are the minimum drive requirements necessary. A good 
example of this would be that the data bus output 
drivers must be able to sink a minimum of 1.6 mA and 
maintain 
VOL at a maximum of 0.5 volts and a mini- 


mum source of 200/-lA,while providing a minimum out- 
put of 2.4 volts. The input specifications are the re- 
quirements on the receivers of the iSBX board. An ex- 
ample of this would be that the loading of the address 
lines (MAO- MA2) can be no greater than 0.5 mA with a 
minimum low threshold of 0.8 volts. 


Optional 
Interface 
Lines 


The iSBX interface has two optional lines which were 
included for the user to configure the iSBX board for 
special application needs. These two lines can be used in 
a number of ways helpful in unique situations. For ex- 
ample, they could be used.as a way to get two extra in- 
terrupt lines down to the host board, thus yielding a 
total of four interrupt lines running between the iSBX 
MULTIMODULE 
board 
and the host board. 
They 


could also be used to get extra address lines, or even 
another clock signal to the iSBX board. They could also 


Bus Signal 
Type2 
IOL Max 
@ Volts 
IOH Max 
@ Volts 
Co Min 
Name 
Drive 
-Min(mA) 
(VOL Max) 
- Min (p.A) 
(VOH Min) 
(pF) 


MDO-MD7 
TRI 
1.6 
0.5 
-200 
2.4 
130 


MINTRO-I 
TTL 
2.0 
0.5 
-100 
2.4 
40 


MDRQT 
TTL 
1.6 
0.5 
-50 
2.4 
40 


MWAITI 
TTL 
1.6 
0.5 
-50 
2.4 
40 


OPTI-2 
TTL 
1.6 
0.5 
-50 
2.4 
40 


MPSTI 
TTL 
Note 3 


Bus Signal 
Type2 
III Max 
@ Volts 
IIH Max 
@ Volts 
CI Max 
Name 
Receiver 
(mA) 
(VIN Max) 
(p.A) 
(VIN Min) 
(pF) 


MDO-MD7 
TRI 
-0.5 
0.4 
70 
2.4. 
40 


MAD-MA2 
TTL 
-0.5 
0.4 
70 
2.4 
40 


MCSOI-MCSI/ 
TTL 
-4.0 
0.4 
100 
2.4 
40 


MRESET 
TTL 
-2.1 
0.4 
100 
2.4 
40 


MDACKI 
TTL 
-1.0 
0.4 
100 
2.4 
40 


IORDI 
TTL 
-1.0 
0.4 
100 
2.4 
40 
IOWRTI 


MCLK 
TTL 
2.4 
0.4 
100 
2.4 
40 


OPTI-OPT2 
TTL 
2.0 
0.4 
100 
2.4 
40 


NOTES: 


J. 
Per iSBX MUL TIMODULE 
board. 


2. TTL = standard 
totem-pole 
output. 
TRI = three-state. 


3. iSBX MULTIMODULE 
board must connect this signal to ground. 


be used to send a special status line to or from the iSBX 
MULTIMODULE board. 


iSBX™ MULTIMODULE™ DESIGN 
EXAMPLE 


This section covers the description of a custom iSBX 
MULTIMODULE board which uses the Intel 8279 Pro- 
grammable 
Keyboard/Display 
Controller. 
This iSBX 


board, when added to an iSBC host board, provides an 
interface to a keyboard and display. A description of 
the hardware design considerations for breadboarding 
the hardware is presented. Following this, a software ex- 
erciser, useful for debugging the board, is described. A 
listing for the exerciser is contained in Appendix C. 


Since the iSBX MULTIMODULE board was designed 
using the Intel 8279 Programmable 
Keyboard/Display 


Controller, a brief description of the 8279 is presented. 
The 8279 is a general purpose programmable keyboard 
and display I/O controller which was designed for use 
with the Intel microprocessors. The keyboard portion of 
this device is capable of providing a scanned interface to 
a 64-contact key matrix. It is also possible to interface to 
an array of sensors or a strobed keyboard, such as those 
of the Hall Effect or the ferrite variety. The 8279 pro- 
vides a variety of keyboard inputs (i.e., 2-key lockout 
and N-key rollover), and all key entries are debounced 


and strobed into an 8-character FIFO. The display por- 
tion provides the user with a scanned display interface 
for LED, incandescent, and other popular display tech- 
nologies. Both numeric and alphanumeric segment dis- 
plays may be used, as well as simple indicators. 
The 


8279 is used in this iSBX design example to provide an 
interface 
of 2-key lockout 
with key debounce 
to a 


64-character keyboard, and an interface for a 16-char- 
acter, 18-segment alphanumeric display. 


iSBX™ MULTIMODULE™ Board Design 


The iSBX board that was designed for this application 
note contains a total of three IC's, the keyboard/display 
controller, a flip-flop, and a 3-to-8-line decoder. Figure 
8 contains a block diagram of the hardware used in this 
design example. Figure 9 contains a schematic for the 
portion of the design example resident on the custom 
iSBX board. 


The design offers the user some flexibility as to the type 
of display or keyboard to be attached. For example, if 
the application design was defined to be for a 7-seg- 
ment, 16-character display (as the 8279 is designed to 
drive), a 4-to-16-line decoder along with the display 
drivers could be added to the iSBX board. Another idea 
would be to include everything except the display drivers 
and the display on the iSBX board, and to put the dis- 


~ 
8279-5 


lORD; 
IiJj 


I 
DI$PLAYI 
IOWRTI 
WR 
ilii 


AO-A3 


Vss 
80-83 


• MPSTI 


play and drivers in with the keyboard. It is possible, and 
probably desirable in some applications, to incorporate 
some of the display electronics onto the iSBX MULTI- 
MODULE board. Some of the IC's found in the display 
portion of this design could also have been placed on the 
iSBX board, as there is enough room on the finished 
product for doing so. 


The design was very easy to implement because, with the 
exception of one signal, all of the iSBX bus signals nec- 
essary to drive the 8279 are connected directly without 
any extra logic needed. The one signal that would not 
connect directly to the interface is the clock signal 
MCLK from the bus to CLK on the controller. It is not 
possible to connect these two together as MCLK is a 10 
MHz signal and the 8279 requires a maximum clock sig- 
nal of 3.1 MHz to generate its internal timings. It is nec- 
essary to add a 74LS74 dual D-type flip-flop to divide 
the MCLK signal by 4 for the controller. With this ex- 
ception, all other signals, DBO-DB7 to MDO-MD7, Ao 
to MAO, CSI 
to MCSOI, 
etc., are connected directly 


to the iSBX interface. To meet the timing requirements 
of the iSBX bus, a high speed version of the 8279, the 
8279-5, is used. 


The keyboard interface side of the iSBX board consists 
of a 3-to-8-line decoder, which is used for scanning the 
keyboard matrix. The 8279 scan lines SLO-SL2 are de- 
coded by a 74LSI56 open-collector output decoder and 
sent to the keyboard via a connector. 


The display interface of the iSBX board consists of 
sending the scan lines and the display outputs to the dis- 
play module via a connector. The scan lines SLO-SL3 
are sent to the display drivers, and the display outputs 
AO-A3 and BO-B3 are sent to an ASCII to 18-segment 
decoder driver. The display is discussed in further detail 
in the next section of this application note. 


Display Module Design 


The display module design (Figure 10) consists of two 
8-digit HDSP 6805 Alphanumeric Displays by Hewlett 
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Packard, 
the AC5947 ASCII to 18-segment decoder 


driver 
by Texas Instruments, 
two Signetics NE590 


Peripheral Drivers, and a 74LSI22 monos table multi- 
vibrator. The display is scanned by the outputs AO-AI 
and BO-B3, which are connected to the inputs of the 
AC5947, and the SLO-SL3 outputs which are connected 
to the NE590 digit scanning circuitry. The interdigit 
blanking is provided by the 74LS122, which prevents a 
display ghosting type effect. With the 8279 display con- 
troller it is possible for the display to have either left 
entry, where the data enters from left to right across the 
display, overflowing in the left most display position, or 
right entry, where the data enters from the right side of 
the display and all previous data shifts left. Left entry 
was chosen for this example. The controller also pro- 
vides commands for blanking or clearing the display. 


The eight output lines from the decoder on the iSBX 
board select l-of-8 keyboard matrix rows for testing by 
the controller to see if a key depression has been made in 
the selected row. The keyboard matrix column output 
lines are connected directly to the return lines of the 
8279, RLO-RL7. Open-collector outputs presented by 
individual keys within the matrix eliminate the need for 
isolation diodes when two keys in a given column are 
depressed. The keyboard/display 
controller has the op- 


tion of using either scan keyboard, scan sensor matrix, 
or strobed input as modes of operation. With the scan 
keyboard mode there is a choice of using either 2-key 
lockout or N-key rollover for keyboard entry. The scan 
keyboard with 2-key lockout mode is used for this ex- 
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ample. 
A diagram 
of the keyboard 
interfaces 
and matrix 
can be seen in Figure 
I-I. 
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Operation with the iSBC 80/10B™ Single 
Board Computer 


The 8279 on the iSBX expansion 
board 
is initialized 
to 
its mode of operation 
following 
a system reset. The key- 


board 
mode 
of operation 
is to scan the keyboard 
with 
2-key 
lockout, 
and 
the 
display 
mode 
is set 
for 
the 
16-character 
left entry mode of operation. 
Upon 
receiv- 
ing a character 
from 
the keyboard, 
the 8279 generates 
an interrupt 
along the MINTRO 
line of the iSBX bus to 
the 
CPU. 
At this 
time 
the 
iSBC 
80/lOB 
board 
com- 
mences 1/0 read operations 
to the iSBX board 
by gener- 
ating 
valid 
I/O 
address 
and 
chip 
select 
commands 
on 
the MAO and MCSOI 
signal lines. After 
the setup 
times 
are met, 
the 
80/lOB 
issues 
an I/O 
read 
command 
by 
asserting 
the 10RDI 
line on the bus, and the base board 
reads 
the data 
from 
the iSBX 
board 
and 
removes 
the 


lORDI, 
MAO, and MCSOI 
signals 
from the bus. After 
the data 
has been read in from the keyboard, 
it must be 
output 
to the display. 
The iSBC 80/lOB 
board 
starts 
an 


I/O 
write operation 
by generating 
a valid 
I/O 
address 
and 
the chip 
select 
signal 
with 
the 
MAO and 
MCSOI 


lines. After 
the valid setup 
times are met, the 10WRT I 


line is activated 
by the base board. 
When 
the data 
has 
been 
valid 
for a minimum 
of 250 ns, 
the 
host 
board 


removes 
the 10WRTI 
line. 
When 
the hold 
times 
have 


been met, the data, 
address 
and chip select lines are also 


removed. 
Figure 
12 shows 
the 
timing 
diagrams 
just 
discussed. 
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Breadboarding the Design 


When 
doing the layout 
of the breadboard, 
it is also nec- 


essary 
to take 
into consideration 
the space required 
by 
the mounting 
holes 
and to plan 
the positioning 
of the 


components 
accordingly. 
(This information 
is available 


in the iSBX Bus Specification 
Manual.) 


When 
attaching 
the 
breadboarded 
design, 
which 
typi- 


cally contains 
raised 
wirewrap 
posts, 
it is necessary 
to 
raise 
the 
breadboard 
well above 
the 
host 
board. 
This 
can be accomplished 
by building 
a small cable and put- 


ting the breadboard 
on longer 
nylon standoffs. 
It is not 


recommended 
that 
the cable 
be longer 
than 
15 cm (6 


in.), 
otherwise 
bus timing 
problems 
could 
result. 


With the breadboarding 
finished 
it is a good idea to re- 


check 
all wiring 
connections 
for possible 
errors. 
Also 


check all signal lines with an ohmmeter 
between 
power, 


and then ground, 
for potential 
shorts. 
An error 
at this 
point 
can cause serious 
damage 
to the host board! 


The software 
written 
for this application 
is an exerciser 


that 
is used 
for hardware 
checkout. 
It is a small 
pro- 


gram 
designed 
to echo characters 
from the keyboard 
to 
the display. 
The software 
was edited, 
assembled, 
linked 
and 
located 
with 
an 
Intel 
development 
system; 
it was 


then 
debugged 
with 
an 
in-circuit 
emulator. 
Both 
the 


software 
and the hardware 
debug 
is covered 
in the next 


section 
of this application 
note. 


To 
facilitate 
this 
discussion 
the 
software 
exerciser 
is 
divided 
into three sections 
based upon the functions 
per- 


formed. 
The three 
functions 
are: 


I) Keyboard 
interrupt 
routine 


2) Initialization 
and 
flag checking 
routine 
3) Character 
output 
routine 


A complete 
listing 
of 
the 
software 
exerciser 
can 
be 


found 
in Appendix 
C. 


The 
8279 generates 
an interrupt 
to the CPU 
whenever 
data 
is introduced 
into its FIFO/Sensor 
RAM. 
The in- 


terrupt 
is cleared 
by doing 
a data read. 
Whenever 
a key 


on the keyboard 
is depressed 
an interrupt 
is generated. 


Two things are required 
when an interrupt 
occurs. 
First, 


the keyboard 
input 
data 
must 
be retrieved 
and stored. 


Second, 
the interrupt 
routine 
must indicate 
that there is 
some data 
ready to be output 
to the display. 
Therefore, 


a buffer 
is created 
in memory 
(called 
"BUFF") 
at loca- 


tion 3COOH to store the keyboard 
data. 
A data 
present 


flag is set in a register 
(REG. 
C) to indicate 
that data 
is 


ready 
to be output 
and 'can be found 
in the buffer. 
In 


this way the interrupt 
routine 
is used to input characters 
from 
the 
keyboard 
to the input 
buffer. 
The 
buffer 
is 
then read by the output 
routine, 
which sends the charac- 


ters to the display. 


INITIALIZATION AND FLAG CHECKING 
ROUTINE 


The initialization 
and flag checking 
routine 
first sets the 
stack pointer 
to the top of memory. 
After 
this the pro- 
gram 
proceeds 
to initialize 
the 8279 Keyboard/Display 


Controller 
to its proper 
mode 
of operation. 
The modes 


of operation 
used 
for this application 
note 
is scanned 
keyboard 
with 2-key lockout 
for the keyboard, 
and 
16 
characters 
with left entry 
for the display. 
As the 8279 
has a desired 
internal 
operating 
frequency 
of 100 kHz, 


the frequency 
divider 
chain is programmed 
to divide by 


19 hex, or 25 decimal. 
After 
the 8279 has been initial- 
ized, the program 
begins 
its next procedure 
of clearing 
the buffers. 
The 
keyboard 
input 
buffer, 
"BUFF", 
as 


well as the display 
buffer, 
"DBUFF", 
are both cleared 
to a blank 
display. 
This is done 
so that 
at the time of 


power 
up, 
the 
display 
will come 
up blank. 
With 
the 
initialization 
now complete, 
the program 
disables 
the in- 
terrupts 
and checks 
the data 
present 
flag for an indica- 
tion that 
data 
might 
be present 
for output. 
If the data 
present 
flag is set, the output 
character 
routine 
is called; 


if it is not set, the interrupts 
are enabled 
and 
the pro- 


gram 
loops 
back 
around 
to check 
again. 
In summary, 


this routine 
initializes 
the 8279 and 
clears 
the buffers, 


and then loops 
on the data 
present 
flag looking 
for an 
indication 
that data 
is present 
in the input 
buffer. 
The 
input 
buffer 
is a one-byte 
wide buffer 
named 
"BUFF." 


The 
character 
output 
routine 
brings 
the 
character 
in 
from 
"BUFF" 
(the 
keyboard 
input 
buffer) 
and 
com- 
pares 
it to the characters 
located 
in a table. 
If the char- 


acter 
can 
be matched 
to a character 
in the table 
it is 


replaced 
in "BUFF" 
with the corresponding 
character 
located 
in the same position 
of a second 
table. 
If there is 


no match, 
it is compared 
to the code for a control 
char- 


acter. 
If there 
is no match 
with a control 
character, 
a 


compare 
is made to see if the character 
is a delete char- 
ater. 
When a match 
is found 
and the acceptable 
charac- 


ter is placed 
in "BUFF", 
the output 
routine 
shifts 
the 


data in the display 
buffer 
(Figure 
13) one position 
to the 


left and places the character 
from 
the input 
buffer 
into 


the display 
buffer 
at position 
"DBUFF" 
+ 15. Now that 


BASE 
ADDRESS 
+15 
169\5**81 


DBUFF 
1 I I I I 
1 


the new information is in the display, the routine copies 
the complete contents of the display buffer, "DBUFF", 
to "DBUFF" + 15 to the display. In the case of the in- 
put character being matched up with a delete character, 
all information 
in the display buffer is shifted to the 


right one position and the ASCII code for a blank char- 
acter is placed into the left-most position or the base ad- 
dress of "DBUFF", 
thus making the next character sent 


to the display a blank character. In the case of a control 
character, nothing is done and the program returns to 
the flag checking routine. 


Debug Considerations 


Hardware and software debug was accomplished using 
an iSBC 801l0B 
Single Board Computer, an iSBC 655 


Chassis, an Intellec@ Series II Model 230 Microcom- 
puter Development System, and an ICE_80™ In-Circuit 
Emulator. 


The software was down-loaded 
from the disk to the 


iSBC 801l0B 
board using the in-circuit emulator. The 


ICET\t module 
gives the engineer the capability 
of 


interrogating the iSBC system by allowing the user to 
access and display the CPU register contents, status, 
system memory contents, and all 110 devices and their 
data. 


The iSBC 801l0B board was configured to enable inter- 
rupts from the iSBX board via the interrupt 
0 line 


(MINTRO), which is connected to the interrupt pin of 
the 8080 CPU. The iSBX board was attached to the 
iSBC 80/IOB board via the iSBX connector. The iSBC 
801l0B board was powered-up and the iSBX board was 


checked for proper power and ground connections. The 
ICE-80 emulator was connected to the iSBC 801l0B 
board. Using the interrogation mode of the emulator, it 
is possible to check proper functioning 
of the iSBX 


board by sending and receiving data to/from 
the 8279. 


The keyboard can be tested by depressing a key on the 
keyboard and then examining the FIFO/Sensor 
RAM to 


see if the data was entered. The display RAM can also 
be read and written to for testing the interface to the 
display. 


After this initial checking of the iSBX board, the soft- 
ware exerciser can then be down-loaded with the ICE 
module to further check the board. 


The objective of this application note is to introduce the 
reader to the iSBX MULTIMODULE 
concept for ex- 
panding a single board computer's functionality, and to 
illustrate how a designer can use this concept with either 
standard or custom iSBX boards. In contrast to system 
expansion using MULTIBUS-compatible boards, iSBX 
MULTIMODULE 
boards provide smaller, lower cost, 


incremental expansion. This application note explains 
how a custom iSBX board can be designed and de- 
bugged. Using this capability, it is now possible to more 
quickly add new VLSI technology to systems as the 
technology becomes available. 
Intel will continue to 


provide new iSBX MULTIMODULE 
boards and, be- 
cause of the the publication of the iSBX Bus Specifica- 
tion and this application note, it will be easier for Intel's 
customers to also design and build their own custom 
iSBX boards. 
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APPENDIX A 


iSBX™ SIGNAL PIN ASSIGNMENTS 


Pin 
Mnemonic 
Description 
Pin 
Mnemonic 
Description 


35 
GND 
Signal Ground 
36 
+5V 
+ 5 Volts 


33 
MOO 
MDATA Bit 0 
34 
MDRQT 
M DMA Request 


31 
MDI 
MDATA Bit I 
32 
MDACKI 
M DMA Acknowledge 


29 
MD2 
MDATA Bit 2 
30 
OPTO 
Option 0 


27 
MD3 
MDATA Bit 3 
28 
OPTI 
Option I 


25 
MD4 
MDATA Bit4 
26 
TDMA 
Terminate DMA 


23 
MD5 
MDATA Bit 5 
24 
Reserved 


21 
MD6 
MDATA Bit 6 
22 
MCSOI 
M Chip Select 0 


19 
MD7 
MDATA Bit 7 
20 
MCSII 
M Chip Select I 


17 
GND 
Signal Ground 
18 
+5V 
+ 5 Volts 


15 
IORDI 
I/O Read Command 
16 
MWAITI 
M Wait 


13 
IOWRTI 
I/O Write Command 
14 
MINTRO 
M Interrupt 0 


11 
MAO 
M Address 0 
12 
MINTRI 
M Interrupt 
I 


9 
MAl 
M Address I 
10 
Reserved 


7 
MA2 
M Address 2 
8 
MPSTI 
iSBX MUL TlMODULE 
Board Present 


5 
RESET 
Reset 
6 
MCLK 
M Clock 


3 
GND 
Signal Ground 
4 
+5V 
+ 5 Volts 


1 
+12V 
+ 12 Volts 
2 
-12V 
-12 
Volts 


APPENDIX 
B 


iSBX™ MULTIMODULE™ BOARD I/O AC SPECIFICATIONS 


Symbol· 
Parameter 
Min(ns) 
Max (ns) 


tl 
Address 
stable 
before 
read 
50 
- 


12 
Address 
stable 
after 
read 
30 
- 


tJ 
Read 
pulse 
width 
300 
- 


t4(2) 
Data 
valid 
from 
read 
0 
250 


tP> 
Data 
float 
after 
read 
0 
150 


t6 
Time 
between 
RD and/or 
WRT 
- 
Note 
3 


t7 
CS stable 
before 
CMD 
25 
- 


ts 
CS stable 
after 
CMD 
30 
- 


t9 
Power 
up reset 
pulse 
width 
50 ms 
- 


tIO 
Address 
stable 
before 
WRT 
50 
- 


tll 
Address 
stable 
after 
WRT 
30 
- 


t12(2) 
Write 
pulse 
width 
300 
- 


t13(2) 
Data 
valid 
to write 
250 
- 


tl4 
Data 
valid 
after 
write 
30 
- 


tiS 
MCLK 
cycle 
100 
110 


tl6 
MCLK 
width 
35 
65 


t17(I) 
MW AIT / pulse 
width 
0 
4 ms 


tiS 
Reset 
pulse 
width 
50 ms 
- 


tl9 
MCS/ 
to MW AIT / valid 
0 
75 


t20 
DACK 
set up to I/O 
CMD 
100 
- 


t21 
DACK 
hold 
30 
- 


t22 
CMD 
(0 DMA 
RQT 
removed 
to end of DMA 
cycle 
- 
200 


t2J 
TDMA 
pulse 
width 
500 
- 


(24(1) 
MW AIT / to valid 
read 
data 
- 
0 


(25(1) 
MWAIT/ 
to WRT 
CMD 
0 
- 


NOTES: 
1. Required 
only if WAIT is aClivaled. 


2. If MWAITI 
not activated. 
3. To be specified by each iSBX MUL TIMODULE 
board. 


• 
For a more complete 
definition 
of symbols 
refer to iSBX 
Bus Specification, 
142686"()()1. 


APPENDIX C 


LISTING FOR THE iSBX™ DESIGN EXAMPLE SOFTWARE 
EXERCISER 


Dora 


OOrl 


0008 


0039 


0040 
0060 
0010 


0080 
0090 


0008 


3eoo 
3000 


0000 
Fl 
0001 
C33BOO 


0038 
0038 
C30100 


003B 
31FFlF 


00][ 
3EO. 


0040 
03r1 
0042 
]E39 


0044 
0]r1 


0046 
]E08 


0048 
O]FI 
o04A 
DEED 


DOte 
21003C 
D04F 
71 
0050 
ObOF 
OOS2 
210flO 


0055 
71 


0056 
2B 


0057 
05 


0058 
C25500 


0058 
Fl 


Dose 
AF 
0050 
B9 
OO~E 
(A6400 


0061 
C06800 


00b4 
FB 


0065 
C]5BOO 


1 1" f •••••••••••••••••••••• 
f •••••••••••••••••••••••••••••• 
f'•••••••••••••••••••• 


2 
;' 
• 
3 
;' 
THIS 
PROGRAM 
VAS 
USED 
AS 
AN 
EXAMPLE 
fOR 
EXERCIsING 
THE 
• 


4 
;. 
8219 
1581 
MULTI NODULE 
8Ul1.>T 
fOR 
THIS 
APPLICATION 
NOTE. 
• 


5 ;' 
• 
6 ;'" 
••••••• 
f •••••••••••••••••••••••••••••••••••••••••••••••.•••••••••••••••••••• 
7 
8 
9 


10 
II 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
2] 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54. 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
b8 
69 
70 
71 
12 
13 
14 
75 
76 


, 
, 
. 


, 
P~OGRAM 
EDUATES 
:'.' 
. 


DATUD 
Eau 
OFOH 
: 
POPT 
AOORJ::SS 
TO 
READ 
OR 
WRITE: 


: IDATA 
TOIOR 
FROM 
KEYBOARD/DISPLAY 


CMDAD 
Eau 
OFtH 
I 
PORT 
ADDRESS 
TO 
SEND 
COMMANDS 
,ITO 
KEYBOARD/DISPLAY 
MOOEO 
Eau 
08H 
, 
CONTROL 
CHAR. 
TO 
SET 


,1te.EYBOARO/OISPLAY 
MODE FOR 
:1(2 
te.EY LOCKOUT,16 
CHAR 
LEFT 
F.NTRY 


PROGCK 
Eau 
]9H 
: 
CONTROL 
CHAR. 
TO 
SEt 
8279 
CLK 
,ITO 
100 
KHz 
INTERNAL 
TIMING 
ROFIro 
Eau 
40H 
: 
CONTROL 
CHAR. 
TO 
READ 
I(EY80ARO 
RDRAM 
Eau 
60H 
, 
CONTROL 
CHAR. 
TO 
READ 
DISPLAY 
RAM 


RDRANA 
Eau 
70H 
: 
CONTROL 
CHAR. 
TO 
READ 
DISPLAY 
RAM 


,IAUTO 
INCREMENT 
IiIRRlM 
E"U 
80H 
, 
CONTL 
CliAR. 
TO 
WRITE 
TO 
DISPLAY 
RAM 


WRRAICA 
Eau 
90H 
, CONTL 
CHAR. 
TO 
WRITE 
TO 
DISPLAY 


,IRUI 
AUTO 
INCREMENT 


CLR 
[au 
OD8H 
I 
COhTROL 
CHAR. 
TO 
CLEAR 
OR 
BLANK 


I/DISPLAY 
BUFF 
Eau 
3COOH 
, 
ADDRESS 
OF 
KEYBOARD 
INPUT 
BUFFER 


DBurr 
Eau 
3000H 
, ADDRESS 
or 
DISPLAY 
BurrER 


; 
. 
; 
INITIALIZE 
PROGRAM 
; 
AND I(EY 
SOARD 
DISPLAY 
CONTROLLER 
, 


BEGINs 
INITIALIZE 
STACte. 
PT 
GET 
CONTROL 
CHAR. 
SET 
KEYBOARD/DISPLAY 
MODE 
GET 
CONTROL 
CHAR. 
SET 
8219 
CLK 
fOR 
100 
KHz 
GET 
CONTROL 
CHAR. 


CLEAR 
OR 
BLANk 
DISPLAy 


SP, lFrFH 
A,MOoEO 
CMDAD 
l,PROGCK 
CMoAo 
A,eLR 
CMDAD 
C,OEOH 
H, BUfr 
H,C 
B,Ot'H 
H, DBurf+OFH 
H,C 


H 
B 
ZOBurF 


S~T 
POINTER 
TO 
INPUT 
8UrfE.R 


CLEAR 
INPUT 
BurrER 
to 
BLANk 


SET 
COUNTER 
= 
15 


SET 
POINTER 
TO 
OBurr 
+1!l 


CLEAR 
DISPLAY 
BurrER 
TO 


;/DISPLAY 
8UfrER 
+15 
TO 
CODE 


: If OR 
CLEARING 
OR 
BLANKING 
OUT 


lITHE 
DISPLAY 


; 
. 


THIS 
IS 
THE 
BACKGROUND 
PROGRAM 
WHICH 
LOOPS 
CHECte.ING 
fOR 
THE 
DATA 
PRESENT 
fLAG 


01 
XRA 
CMP 
JZ 
CALL 
EI 
JHP 


A 
C 
LABlL 
OUTPT 


DISA.BLE 
INTERRUPTS 


ICLEAR 
A REG 
AND COMPARE 
WITH 
IC 
REG 
CHECIONG 
fOR 
DATA 
PRESENT 


IIf 
PRESf;NT 
CALL 
OUTPT 
ITO 
DISPLAY 
CHAR. 


IIr 
NO DATA. PRESENT 
ENABLE 
IINTERRUPTS 
AND 
JJltp 
BACte. 


00b8 
lAOOlC 


0068 
0628 


0060 
210EOO 


0010 
110901 
0013 
8E 
0074 
CABOOO 
0011 
05 
0078 
CAC600 


0018 
23 
007C 
Il 
0010 
C31300 


0080 
E8 
0081 
1E 
0082 
2100lC 


0085 
11 
00(:16 Obor 


0088 
1I00lO 
0088 
210110 


oo(:lE 1[ 
008r 
23 
0090 
£8 
0091 
11 
0092 
2l 
0093 
£8 
0094 
05 
0095 
C28£00 
009(:1 3A003e 
009B 
]2ono 


DOgE 0610 
OOAO 
210010 


00A3 
1E 
00A4 
03ro 
00A6 
23 
00A1 
05 
OOAB 
C2AlOO 
00A8 
OEOO 
OOAo C9 


OOAE 060r 
0080 
110F3o 
0083 
210E3o 


0086 
1£ 
0087 
28 
00B8 
E8 
0089 
17 
008A 
2B 
00B8 
E8 
OOBC 
05 
0080 
C28600 
OOCO 
EB 
OOCI 
36EO 
OOCl 
Cl9EOO 


OOC6 
FEFA 


00C8 
CA3800 


OOCB 
fEr9 


OOCO CAAEOO 
0000 
C9 


0001 
3E40 


0003 
o3Fl 
0005 
oaFO 
0007 
21003C 


oOOA 
77 
OODB 
OEFr 


DODD 
C9 


LOA 
NVI 
LXI 
LXI 
CHP 
JZ 
OCR 
JZ 
INX 
INX 
JNP 
XCHG 
HOV 
LXI 
NOV 
NVI 
LXI 
LXI 
NOV 
lOX 


XCHG 
NOV 
I"X 
XCHG 
OCR 
8 
: 
T£ST 
·IF 
DONE 


IN% 
LOOPI 
llANO 
GO 
BACK 
If 
NOT 
LOA 
aUfr 
; IELSE 
READ 
KEYBOARD 
DATA 
STA 
DBUFF+orH 
llANO 
PLACE IT 
IH THE DaUFf 


/lilY I 
B,10H 
I 
SET COUNTER = 
16 
LXI 
H,DBurr 
; 
SET 
POINTER 
~ 
OBurf 
1ST 
POSe 
MOV 
A,'" 
;/READ 
1 
BYTE 
FROM 
DBUFr 


OUT 
DATAAD 
;/AND 
SENT 
IT 
TO 
OI5PL"Y 


IhX 
H 
; 
UPDATE 
POINTER 
OCR 
8 
; lAND 
T£5T 
IF 
DONE 
JNZ 
LOOP2 
; IGo 
BACK 
IF 
NOT 
DONE 
MVI 
C, 
pH 
I/ELSE 
eLR 
DATA 
PRESENT 
FLAG 
RET 
I I AND 
RETURN 
; ••••••••••••••••••••••••••••••••• 
*•• *•• *•.••.••••••••••••••••••••••••••••••••••• 


CHARACTFR 
DfLETE 


OR 
RUB 
OUT 


Burr 
8,28H 
H,TABLEI 
D,TABLE2 
H 
IUTCH 
B 
CONTROL 
H 
o 
COMPARE 


A.N 
H, BUfr 


N ,A 
B,orH 
D,DBurr 
H, DBurF. 
1 
A.N 
H 


NVI 
LXI 
LXI 
NOV 
OCX 
XCHG 
NOV 
OCX 
XCHG 
OCR 
JOZ 
ICHG 
NVI 
JHP 


a,OFH 
D,D8UfF.OfH 
H,DBurF.OEH 
A .N 
H 


LOAD 
A 
WITH 
KEYaO"AD 
DATA 
SET 
COUNTER 
MAX 
POSSIBLE 
CHAR. 
, 
SET 
POINTER 
TO 
INPUT 
tABLE 


SET 
POINTER 
TO 
OUTPUT 
TABLE 


CONPARE 
KEYBO 
DATA 
TO 
INPUT 
; IT"BLE 
IF 
= JMP 
to 
MATCH 
;/ELSE 
OECREMENT 
COUNTEf!: 
IF 
0 
: IJMP 
TO 
CONTROL 
; IELSE 
INCREMENT 
80TH 
TABLE 
; /POINTERS 
AND 
JMP 
TO 
COMPARE 


SET 
COUNTER 
:: 
TO 
15 
POINTER 
TO 
FIRST 
LaC 
IN 
OBurr 
POINTER 
TO 
2ND 
LaC 
IN 
OBurr 
READ 
HIGH 
POINTER 
FROM 
DBurf 
I/UPO"TE 
HIGH 
POINTER 


SET 
COUNTER 
=15 
SET 
POINTER 
:: 
DEtUrF.15 


, 
SET POINTER = DBUrf'.14 
READ 
LOW 
POINTER 
fRO" 
D8UFF 
'/UPDAT£ 
LOW 
POINTER 


TESt 
If 
DONE 
;/ANo 
GO 
BACK 
IF 
NOT 
: IELSE 
SET 
DourF 
fOR 
,/COo£ 
to 
BLANK 
DIspLAY 
;I AND 
JMP 
TO 
LOOPA 
, 
_ 
. 
, 
CHECK 
IF 
CHARACTER 
IS 


: 
A CONTROL 
OR 
DELETE 
CHARACTER 
, 


CO~TROL; 
OrAH 
BEGIN 
or9H 
DELETE 


; 
COMPARE 
FOR 
CONTROL 
CHAR. 
:IIf 
CONTROL 
JMP 
TO 
BEGIN 
;/ELSE 
COMP. 
rap: 
DELETE 
CHAR. 
r IIr 
DELETE 
JMP 
TO DELETE 
; IELSE: 
RETURN 
I···· 
. 
KEYBOARD 
INPUT 


INTERRUPT 
ROUTINE 


It, RoFIro 


C"DAD 
DATAAO 
H,Burr 
H.A 
C,OFFH 


, 
GET 
CDNTL 
CHAR. 
TO 
READ 
FIro 


: 
SET 
8219 
FOR 
READ 
MODE 
; 
READ 
KEYBOARD 
DATA 
IN 
; 
SET 
POINTER 
TO 
BurF 
;/AND 
STORE 
KEYBOARD 
DATA 
,/THEN 
SET 
DATA 
PRESENT 
FLAG 
; lAND 
RETURN 


OOOE 
DE 


000' 
" 
ODED 
EF 
00E1 
EE 
00E2 
E5 


00E3 
'6 
00E4 
FE 
00E5 
C6 
00£6 
C9 
00£1 Cl 
00E8 
02 
00E9 
OA 
OOEA 
03 
OOEB 
C7 
OOEC 
01 
ODED 
09 
OOEE 
05 
DOEr 
ED 


00'0 
E6 
Don r5 
oor2 c 1 
OOFl 
F1 
oor4 
DO 


00'5 
E7 
00r6 
ro 
oon 0' 
OOFe 
CC 
00,.9 
D4 
oorA 
DC 
oorB 
!4 
oorc 
EC 
oorD 
,. 
00f[ 'C 
oorr 
CO 
0100 
C8 
0101 
DO 
0102 
98 
0103 
A2 
0104 
cr 
0105 
Al 
0106 
EB 
0107 
E3 


0108 
08 


, 
. 


, 
TABLE 
1 
, 
ACCEPTABLE 
INPUT 
CHARACTERS 
rROO 
KEYBOARD 
, 
TABLEt: 
DB 
ODEH,OFFH. OEFH, OE£H,O~5H,or6H 
,orEH, 
oC6H 


169 
: .•"•• "•• f" 
f •••••••••••••••••.••••••••.•••..••••••..••. 
f •••. 
" •••• 
f •••.•.•• 
f ••.•••••••.•.•••• 
170 
I 
TABLE 
2 
171 
ACCEPTABLE 
OUTPUT 
C~A"ACTEPS 
TO DISPLAY 
172 
I 


0109 
CI 
173 
TABLE2: 
DB 
oCl 
H, OC2H, 
oe3H, 
OC4H, 
OCSH, 
oe6H, 
oe1H, 
oC9H 


OIOA 
C2 
OIOB 
Cl 
OIOC 
CO 
0100 
C5 
OIOE 
C6 
olor 
C7 
0110 
C8 
0111 
C9 
174 
OB 
OC9H ,0eAH, 
oCBH, 
OCCH, 
oeOH, 
OCEH, 
OCFk ,000H 


0112 
CA 
0113 
CB 
OliO 
CC 
0115 
CO 
0116 
CE 
0117 
cr 
0118 
00 
0119 
01 
175 
DB 
001 H ,002H, 
003H, 
004H, 
GOSH, 006H, 
o07H, 
o08H 


011A 
02 
OIlB 
0) 
OIlC 
00 
0110 
05 
011E 
06 
011F 
07 
0120 
08 
0121 
09 
176 
DB 
009H, 
ODAH, Oft 
H, OF2H, 
or3H, 
or4H, 
OfSH, 
or6H 


0122 
OA 
0123 
r1 
0120 
r2 
0125 
r3 
0126 
ro 
0127 
r5 
0128 
r6 
0129 
r7 
171 
DB 
or7H, 
or8H, 
or9H, 
orOH, 
orOH, 
OEBH, 
OEOH, 
OEAH 


o12A 
r8 
012B 
r9 
012C 
ro 


0120 
ro 
012E 
EB 
012r 
EO 
0130 
EA 
0131 
Er 
178 
DB 
OErH, 
OEEH, o7Ott 


0132 
EE 
01)) 
20 
0000 
179 
END 
START 


PUBLIC 
SYMBOLS 


EXTERNAL 
SYMBOLS 


USER 
SYMBOLS 


BEGIN 
.•. 0038 
BUfF 
)COO 
CKFLAG 
0058 
CLR 
0008 
(MOAD 
oort 
COMPAR 
0073 
CONTRO 
00C6 


OATlAO 
l 
ooro 
DBun' 
)000 
DELETE 
oolE 
INT 
0001 
LABEL 
0064 
LOOPt 
008E 
LOOP2 
OOA) 
LOOP" 
A 
D09E 
LOOPS 
0086 
MATCH 
0080 
MODEO 
0008 
OUTPT 
0068 
PROGCK 
00)9 
RDFlfO 
0000 
RDRA" 
A 
0060 
RDR""A 
0070 
START 
0000 
1'ABLEl 
OOOt. 
TABL£2 
0109 
llIRRAM 
0080 
WRRAMA 
0090 


Z08urr 
A 
0055 


ASSEMBLY 
COMPLETE, 
NO ERRORS 


iCS Industrial Control 
Series and Analog I/O 
Expansion 
10 


iCS 910/920/930 
SIGNAL 
CONDITIONING/TERMINATION 
PANELS 


• Interconnects iSBC and digital 
I/O ports 
to field signal/control wiring 


• Ribbon cable connection from panel is 
pin compatible with iSBC analog, CPU, 
and digital board I/O ports 


• Barrier strip screw terminals for 
- 
iCS 910: 32 single·ended analog 
inputs (or 16 differential signal plus 
shield) plus four analog voltage 
outputs or two analog 4 to 20 mA 
current outputs 
- 
iCS 920: 24 medium power digital 
inputs and/or outputs (55V, 300 mA 
max) 
- 
iCS 930: 16 high power AC or DC 
digital inputs or outputs (280 VAC, 
3A max) 


• Flexible mounting kits for 
- 
19" width RETMA rack 
- 
NEMA type backwall 
- 
iCS 80 Industrial Chassis 


• Digital signal conditioning (iCS 920/930) 
- 
Sockets for optically isolated input 
filters and solid state output 
switches 
- 
Pad space for transient suppres· 
sors, current limiting resistors, 
and voltage dividers 
- 
Socketed fuse for overload 
protection (iCS 930) 
- 
LED/channel status indicators 


• Engineering printed circuit mounting 
space for customer analog input 
components (iCS 910) 
- 
Noise fiters 
- 
Current loop resistors 
- 
Open circuit detection resistors 
- 
Voltage divider resistors 
- 
Thermistor bias current 


The 
iCS 
910/920/930 
Signal 
Conditioning/Termination 
Panels 
are 
heavy 
duty 
printed 
circuit 
boards 
with 
screw 
terminations 
which 
allow 
industrial 
customers 
to easily connect 
their heavier gauge field signal wiring 
to Intel's line of 8- 
and 16-bit single board computers, 
and iSBC analog and digital 
I/O boards. 
Flat ribbon 
cables connect 
the iCS 910 panels 
to any of the Intel iSBC 700 series analog 
input and output 
board 
pin-outs. 
Flat ribbon 
cables also connect 
the iCS 920 
panels and iCS 930 panel to the 50-pin 
digital 
I/O ports 
(8255 or UPI) on Intel's single 
board 
computers 
and digital 
I/O 
boards. 
Power for opto-isolators 
or line drivers 
(+5 VDC) can be supplied 
via this cable from the iSBC boards. 
Jumpers 
and a screw terminal 
block 
are provided 
on the iCS 920/930 
panels to allow an external 
supply 
of +5V power. 
A similar 
jumper/terminal 
block 
is provided 
on the iCS 910 panel to allow 
users to connect 
external 
+15V (or greater) 
compliance 
voltage 
for larger 
analog 
output 
loads. 


FUNCTIONAL 
DESCRIPTION 
COMMON 
TO iCS 910/920/930 


Large Wire or Spade Lug Connections 


The barrier 
strip 
screw terminations 
on the iCS 910/920/ 
930 panels provide 
familiar 
connection 
points 
for factory 
electricians 
to terminate 
the heavier 
gauge 
wiring 
often 
pulled 
through 
conduits 
from 
sensors 
or 
control 


elements. 
These screw terminals 
securely 
connect 
up to 
14 AWG 
gauge 
wire 
size 
(16-gauge 
on 
iCS 
910/920 
panels). 
Alternately, 
spade lugs can be crimped 
on field 
wiring 
and inserted 
under 
the screw terminals. 


Mounting Flexibility and Serviceability 


The 
iCS 
910/920/930 
panels 
were 
designed 
to 
be 


physically 
separate 
from 
iSSC 
boards 
or 
the 
iCS 
80 


chassis to allow maximum 
mounting 
flexibility 
and ease of 


serviceability. 
The 
panels 
and 
field 
wiring 
can 
be 


mounted 
in one 
area of the cabinet 
where 
electricians 
have access. 
Flat ribbon 
cable can then be run to the area 
where 
control 
electronics 
technicians 
have access. 


The iCS 910/920/930 
panels may be mounted 
horizontally 


in a 19" standard 
width 
(RETMA) 
rack using 
a recessed 


mounting 
panel 
(see Figure 
1). Alternately, 
the panels 


can 
be mounted 
on a cabinet 
wall 
(e.g., NEMA 
cabinet 


backwall) 
using standoffs 
provided 
(see Figure 2). Or, for 


the most compact 
packaging, 
users can mount 
up to two 


iCS 910/920/930 
panels vertically, 
directly 
on the front of 
the iCS 80 chassis using standoffs 
and holes provided 
(see 
Figure 
3). 


A black 
metal 
labelling 
strip 
is provided 
with 
each 
iCS 
910/920/930 
panel. 
White, 
blank 
gummed 
labels 
are in· 
cluded 
so that 
users 
can custom 
identify 
each input 
or 


output 
channel. 
A clear 
plastic 
cover 
is provided 
to pro· 
tect 
against 
inadvertent 
touching 
or 
damage 
to 
the 


screw 
terminals 
or customer 
mounted 
components. 


Figure 
1. iCS 930 AC and iCS 920 Digital 
Signal 


ConditioninglTermination 
Panel 
Mounted 
on 


a 19" Width 
RETMA 
Rack 


Figure 
2. iCS 910/920 
Signal 
ConditioninglTermlnatlon 
Panel 
Mounted 
on a NEMA 
Cabinet 
Backwall 


Figure 
3. iCS 910/930 
Signal 
Conditioning/Termination 
Panels 
Mounted 
on iCS 80 Industrial 
Chassis 


iCS 910 ANALOG SIGNAL 
CONDITIONING/TERMINATION 
PANEL 


Mixed Analog Input and Output Signals 


A single 
iCS 910 panel 
connects 
up to 32 single 
ended 


analog 
inputs 
(or 16 differential 
analog 
inputs plus shield) 


to the 
iSSC 
711 or 
iSSC 
732 analog 
input 
boards. 
In 
addition, 
the same iCS 910 panels can connect 
up to four 


analog 
output 
voltages 
from the iSSC 724 analog 
output 


board, 
or two voltage 
or 4 to 20 mA current 
loop outputs 


from 
the 
iSSC 
732 combination 
analog 
input/output 


board. 
Three 
flat 
ribbon 
cables 
are included 
in the iCS 
910 installation 
kit (two analog 
inputs, 
one analog output) 


to route 
signals 
to iSSC 711/724/732 
boards. 


Engineered 
Signal Conditioning 
Mounting 
Space 


Printed 
circuit 
traces 
on the iCS 910 panel connect 
each 


screw 
terminal 
analog 
input 
channel 
to the flat 
ribbon 


cable connector. 
Users can jump straight 
through 
signal 
connections 
if they 
desire. 
Each 
Input 
channel 
trace, 
however, 
passes 
through 
a custom 
engineered 
printed 


circuit 
area onto which 
users may mount 
components 
to 


signal 
condition 
analog 
input 
Signals. 
Pad 
traces 
and 


holes are designed 
to allow 
easy mounting 
of R-C noise 


filters, 
input 
voltage 
resistor/divider 
networks, 
current 


loop input resistors, 
open circuit 
detection 
resistors, 
or to 


supply 
thermistor 
bias current 
(see Figure 4 for schematic 


of a typical 
analog 
input 
channel). 


RIBBON 
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TO 
iSBC-7111732 
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iCS 920 DIGITAL SIGNAL 
CONDITIONING/TERMINATION 
PANEL 


The iCS 920 panel 
interconnects 
up to 24, 2-wire 
digital 


input or output 
channels 
from barrier strip screw terminals 
to the 16- or 24-bit 
digital 
I/O ports, 
standard 
on many 
Intel 
single 
board 
computers 
and digital 
I/O expansion 
boards. 
Screw terminals 
allow for one each 16 AWG size 
wire 
for 
differential 
(2-wire) 
connections 
or two 
each 
AWG 18-gauge 
wire for daisy chaining 
grounds 
or power 


for external 
contact 
sensing. 


Flexibility 
in Isolation and Serviceability 


Dual-in-line 
sockets 
are in series 
with each channel 
(see 
Figure 
5) 
to 
allow 
customer 
jumpering 
for 
straight 
through 
connections 
(TTL 110), or for insertion 
of popu- 


lar DIP packaged 
opto-isolators 
or digital 
output 
high 
current 
driver 
transistors. 
Circuit 
pads are available 
for 


mounting 
voltage 
dividerlthreshold 
resistors 
and protec- 
tion 
diodes. 


Groups 
of 
four 
inputs 
can 
have mixed 
voltage 
levels, 


opto-isolation, 
or 
straight 
through 
connections 
in 


groups 
of two. Output 
groups 
of four can be mixed 
opto- 


isolated 
or high current 
drive in groups 
of two. DIP com· 


ponents 
from a wide variety 
of vendors 
are selected 
and 


inserted 
by users 
based 
on their 
application. 
The 
iCS 


920 
manual 
recommends 
several 
alternative 
compo- 


nents 
and offers 
design 
assistance 
for your I/O configu- 


ration. 
Digital 
signal 
conditioning 
examples 
for several 
common 
industrial 
voltages 
are shown 
in Table 
1 and in 


the diagrams 
below 
(see Figure 
5). 


Active Channel Indicators 


Light 
emitting 
diodes 
(LEOs) are mounted 
adjacent 
to 


each channel's 
screw 
terminals 
and may be jumpered 
in 


to indicate 
the 
Hi-Lo 
status 
of each 
of the 24 input 
or 


output 
channels. 


CURRENT LIMITING 
AND 
THRESHOLD 
RESISTORS 


I 


iSBC 902 
I 


I 


I 
-=- 
10F4 
I 
I CHANNELS 
I 
L 
..J 


OPTO·ISOLATOR 
+ 
SOCKETS 


(e.g.,TlL113) 
1-----, 
I 
I 


1 


+'I 


I 
I 


I 
I 


L- 
.J 


LINE DRIVE·R 
,-------l 
I 
e.g. TI 75472 
I 
I 


1 OF 2 
l..- __ 
~A~N'::=-__ J 
I 


I 
-l 


I 
I 
L 
J 


Digital 
Voltage 
Input 
or 
Maximum 
Input Current 
Threshold 
Voltage 
Opto-Isolators' 
Diode Protection' 
Output 
Load Voltage 
(mA) 
(V) 


Opto-Isolated 
Input 


5 VDC 
50 
3 
TIL117 
1N4002 
12 VDC 
50 
6 
TIL117 
1N4002 
24 to 26 VDC 
40 
6 
TIL117 
1N4002 


48 VDC 
20 
12 
4N36 
1N4002 


Maximum 
Output 
Current 
Line Driver' 
Opto-Isolators' 
(mA) 


Opto-Isolated 
Output 


12 VDC 
100 
- 
TIL113 
24 VDC 
100 
- 
, 
TIL119 


48 VDC 
100 
- 
MCS 2 


Current 
Drivers 


55 VDC 
300 
T175472 
- 


Half Wave Rectifier 
Outputs 


24 VAC SCR 
300 
- 
GE4N40 
115 VAC SCR 
150 
- 
MCS 2 


-Example 
component 
- 
alternate 
source 
components 
are listed 
in the iCS 920 Hardware 
Reference 
Manual. 


iCS 930 AC Signal Conditioning/Termination 
Panel 


The iCS 930 panel interconnects 
16 2-wire 
digital 
input or 
output 
channels 
from 
barrier 
strip screw terminals 
to 16 
bits of the digital 
I/O ports available 
on many Intel single 
board computers 
and digital 
I/O expansion 
boards. 
The 
iCS 
930 panel 
differs 
from 
the 
iCS 
920 digital 
signal 
conditioning/termination 
panel in that the iCS 930 panel 
handles 
higher 
AC or DC voltages 
and currents 
(up to 
280V, 
3A), 
such 
as those 
found 
on 
many 
115 VAC 
machines, 
motor 
starters, 
and industrial 
control 
panels. 
The 
iCS 
930 panel 
is also 
recommended 
for 
optically 
isolated 
DC outputs 
greater 
than 
100 mA. 


The iCS 930 screw 
terminals 
accept 
up to 14 AWG size 
wire 
each 
for differential 
(2 wires 
per channel) 
connec- 
tions, 
or 
two 
14 AWG 
size 
wires 
for 
daisy 
chaining 
grounds 
or power 
from 
external 
sources. 


Modular 
Isolation/Switching 
with Easy 
Serviceability 
\ 


Each 
iCS 930 panel accepts 
up to 16 user supplied, 
op- 
tically 
isolated 
input 
modules 
or optically 
isolated 
solid 
state 
switches, 
for either 
AC or DC voltages 
(see Figure 
6). Each 
module 
is 
screw 
mountable/replaceable 
and 
can be mixed 
for AC or DC input, 
or AC or DC output, 
in 
groups 
of four. Among 
groups 
of four inputs 
(or outputs) 


each channel 
can be individually 
mixed 
for AC or DC in- 
put (or AC or DC output). 
The user pays only 
for those 
channels 
implemented. 
User supplied 
compatible 
mod- 


ules are shown 
in Table 2. 


DC and AC input 
modules 
are current 
actuated 
and thus 
provide 
a 5-ms filter 
against 
spurious 
noise 
spikes 
or 
contact 
bounce. 
AC solid 
state 
output 
modules 
provide 
zero crossing 
turn on to minimize 
arcing. 


Each of the 16 channels 
contain 
a socketed 
fuse to pro- 


tect 
against 
overload. 
In addition, 
mounting 
pads 
are 
available 
on each channel 
output 
for user supplIed 
volt- 
age transient 
RC "snubber" 
components 
or inductive 
pulse 
suppression, 
e.g., 
metallic-oxide-varistor 
(MOV) 
for large motor 
starting. 


Light 
emitting 
diodes 
(LEDs) are mounted 
adjacent 
to 
each 
channel's 
screw 
terminals 
and 
opto-module 
to 
indicate 
Hi-Lo 
status 
of that 
channel 
and to assist 
in 
troubleshooting 
servicing. 


Examples 
of iCS 930 input 
and output 
schematics 
are 
shown 
in Figure 
6. 


Signal 
Conditioning 
Desired 
Voltage 
Rating 
Maximum 
Input Current 
Opto·22 
Number- 
Motorola 
Number- 


AC 
input 
- 
115 VAC 
95 to 130 VAC 
10 mA 
IAC5 
IAC5 


220 VAC 
180 to 280 VAC 
10 mA 
IAC5A 


DC Input 
- 
5 "see 
Filter 
10 to 32 VDC 
32 mA 
IDC5 
IDC5 
Fast, 50 "see 
On 
4 to 
16 VDC 
14 mA 
IOC5S 


Output 
Current 
Rating 


AC Output 
12 to 
140 VAC 
3A 
OAC5 
OAC5 
24 to 280 VAC 
3A 
OAC5A 


DC Output 
10 to 
60 VDC 
3A 
ODC5 
ODC5 


200 VDC 
lA 
ODC5A 


·Motorola 
and Opto-22 sales offices 
are located in North America, 
Europe, and Japan. 
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SPECIFICATIONS 
(For iCS 910/920/930 
panels unless otherwise 
specified) 


iCS 910 Panel 


Analog 
Inputs 
- 
Sixteen 
3-wire 
(differential 
signal 
plus 


shield) 
or 32 single 
ended 


Analog 
Outputs 
- 
Four 2-wire 
voltage 
output 
(iSSC 724 
Analog 
Soard) 
or two 
2-wire 
current 
output 
(iSSC 
732 
Analog 
Soard) 


iCS 920 
Panel 
- 
Zero to 24 digital 
inputs 
or outputs 
in 


groups 
of four 


iCS 930 
Panel 
- 
Zero to 16 digital 
inputs 
or outputs 
in 


groups 
of four 


Isolation Characteristics 


L1ne-to-Line 
Isolation 
- 
250 VDC 
or 
RMS 
AC 
(iCS 


910/920 
panels), 
500 VDC or RMS AC (iCS 930 panel) 


Input/Output 
Isolation 
- 
250 VDC or RMS AC (iCS 920 
panel). 
500 VDC or RMS AC (iCS 930 panel) 


Physical Characteristics 


Width: 
36.63 cm (14.65 in.) 


Height: 
8.13 cm (3.25 in.) 
Thickness: 
0.24 cm (0.093 in.), iCS 910/920 
panel 


0.32 cm (0.125 in.), iCS 930 panel 


Weight: 


455 gm(16 Ol) 


(Minimum, 
PC panel only) 


455 gm (16 Ol) 
681 gm (24 Ol) 


(Maximum 
with all components 
and mounting 
kit installed) 


1.6 Kg (58 Ol) 
1.8 Kg (64 Ol) 
3.4 Kg (120 Ol) 


Depth: 
(With components 
and clear plastic cover installed) 


5.08 cm(2.0 in.) 
5.08 em (2.0 in.) 
5.08 cm(2.0 in.) 


Connectors: 


2156 screws 


48 AI 
12 AO 
2 power 


(Barrier strip) 


2156 screws 


4801100 
2 + 5V power 


6132 screws 


3201100 
2 + 5V power 


(J1, J2, J3 to iSSG boards) 


50·pin 
50·pin 
50·pin 
0.1 in. centers 
0.1 in. centers 
0.1 in. centers 


~~m~ 
~~m~ 
~~m~ 


(Mating 
connector: 
3M 3415·סס OOor TI H3·12125) 


Maximum Distance from iSBC Boards 


The iCS 910/920/930 
panels 
are shipped 
with 4-ft. 
long 
cables. 
With customer 
provided 
50-conductor 
or twisted 


pair ribbon 
cable, 
however, 
the iCS 910/920/930 
panels 


can be mounted 
remote 
from the iSSC analog 
or digital 


1/0 
boards. 
In electrically 
quiet 
environments 
using 


normal 
iSSC 
board 
line 
driverlreceivers, 
the 
iCS 


910/920/930 
panels should 
be able to operate 
up to 25 ft. 


(7.69m) from the iSSC board. 


Power 
Requirements 


iCS 920 panel- 
+15V ±5%, 25 mA max if iSBC 724 or iSBC 
732 ±15V 
power 
is used for user mounted 
open 
circuit 
detection, 
or thermistor 
bias components. 
Additional 
power 
must be supplied 
via +15V terminal 
block. 


iCS 920 panel 
- 
+5V ±5%, 1.46A max (24 channels 
high 
current 
drive) 


ICS 920 Channol 
Maximum 
per Channel 
Current 
(Includes 
pullups, 
LEOs, 
ContlgureUon 
isolators, 
drivers) 


TILin 
23 mA 
ITLout 
23 mA 
Opto·isolated 
in 
23 mA 
Opto-isolated 
out 
41 mA 


I 


Open collector 
driver 
61 mA 


output 


iCS 930 panel - 
+5V ±5%, 320 mA max. 
Output 
AC or DC 
channel: 
20 mAichan 
max; 
Input 
AC or DC channel: 
12 
mA/chan 
max. 


Maximum 
Power 
Dissipation 


iCS 910 panels 
- 
3 watts 
with 
16 channels 
analog 
input 
signal conditioning 
and +15V external 
compliance 
voltage 


iCS 
920 
panels 
- 
12 watts 
with 
24 channels 
each 
containing 
high current 
driver 
outputs 


iCS 930 panels - 
80 watts with 
16 channels 
of AC or DC 
output 


Underwriters 
Laboratory 
(ULl 
Recognition 


The 
iCS 910/920/930 
signal 
conditioning/termination 
panels have been submitted 
to Underwriters 
Laboratories 
for approval 
as a UL recognized 
component 
under the UL 
safety 
standard 
for process 
control 
equipment, 
UL 1092. 


Environmental 
Characteristics 


Operating 
Temperature 
- 
0 to 70°C 
(32°F to 158°F) 


Relative 
Humidity 
- 
0 to 90%, 
noncondensing 


Hardware Supplied 


ICS 
910 
- 
Analog 
Signal 
Conditioning/Terminating 
Panel, 
three 
4-ft, 
50-conductor 
flat 
ribbon 
cables 
with 
I 


connectors, 
and installation 
kit below 


ICS 
920 
- 
Digital 
Signal 
ConditioninglTermination 
Panel, one 4-ft, 50-conductor 
flat 
ribbon 
cable 
with 
con- 
nectors, 
and installation 
kit below 


ICS 930 - 
AC Signal 
Conditioning/Termination 
Panel, 
one 4-ft, 50-conductor 
ribbon 
cable with connectors, 
and 
installation 
kit below 


Installation 
kit consisting 
of RETMA 
(19" 
rack) 
mount- 
ing 
bracket, 
clear 
plastic 
safety 
cover, 
labelling 
strip 
with 
blank gummed 
labels, 
hex standoffs 
and mounting 
screws 


Documentation 
Supplied 


A schematic 
diagram 
and assembly 
diagram 
are supplied 
with each iCS 910/920/930 
panel. 


Reference Manuals 


9800800A 
- 
iCS 910 Analog 
Signal 
ConditioninglTermi- 
nation 
Panel 
Hardware 
Reference 
Manual 
(NOT 
SUP- 
PLIED). 


9800801A 
- 
iCS 920 Digital 
Signal 
Conditioning/Termi· 
nation 
Panel 
Hardware 
Reference 
Manual 
(NOT 
SUP- 
PLIED) 


9800802A 
- 
iCS 930 AC Signal 
ConditioninglTermina- 
tion 
Panel Hardware 
Reference 
Manual (NOT SUPPLIED) 


9800798A 
- 
iCS 80 Systems 
Site Planning 
and Installa- 
tion 
Guide 
(NOT SUPPLIED), 
but supplied 
with 
iCS 80 
Industrial 
Chassis 


Reference 
manuals 
are shipped 
with 
each product 
only 
if designated 
SUPPLIED 
(see above). 
Manuals 
may 
be 
ordered 
from 
any Intel 
sales 
representative, 
distributor 
office 
or from 
Intel 
Literature 
Department, 
3065 Bowers 
Avenue, 
Santa 
Clara, 
California 
95051. 


Complete 
instructions 
for 
installation 
and 
service 
are 
contained 
in the 
applicable 
iCS 910/920/930 
Hardware 
Reference 
Manual. 
Additional 
system 
level information 
is available 
in the iCS 80 Systems 
Site 
Planning 
and In- 
stallation 
Guide, 
including 
RETMA 
and 
NEMA 
cabinet 
mounting, 
field 
signals, 
ground 
wiring 
and cooling 
sug- 
gestions. 


Warranty 


The 
iCS 80 Industrial 
Chassis 
is warranted 
to be free 
from 
defects 
in materials 
and workmanship 
under 
nor- 
mal use and service 
for a period 
of 90 days from date of 
shipment. 


Part Number 
Description 


iCS 910 
Analog 
signal 
conditioning/ 


termination 
panel 


iCS 920 
Digital 
signal 
conditioningl 
termination 
panel 


iCS 930 
AC signal 
conditioning/termination 
panel 


iSBX 328 
ANALOG OUTPUT MULTIMODULE 
EXPANSION BOARD 


• Low cost analog output for iSBX MULTI- 


MODULE compatible iSBC Boards 


• 8 channels output, current loop or 


voltage in any mix 


• 4-20 mA current loop; 5V unipolar or 


bipolar voltage output 


• 12·bit resolution 


.0.035% 
full scale volage accuracy 


@ 25°C 


• Connector compatible with ICS 910 


Analog Termination 
Panel 


• Intel design based on UPI control for 


high density and low cost 


• Programmable offset adjust In current 


loop mode 


The Intel iSBX 328 MUL TIMODULE 
board provides 
analog signal 
output 
for any iSBC board which 
has an 
iSBX compatible 
bus and connectors. 
The single-wide 
iSBX 328 plugs directly 
onto the iSBC board, pro- 
viding 
eight 
independent 
output 
channels 
of analog 
voltage 
for 
meters, 
CRT control, 
programmable 
power supplies, 
etc. Voltage 
output 
can be mixed with current 
loop output 
for control 
of popular 
4-20ma 
industrial 
control 
elements. 
By using 
an Intel 
single 
chip 
computer 
LSI (8041) for refreshing 
separate 
sample-hold 
amplifiers 
through 
a single 
12 bit 
DAC, eight 
channels 
can 
be contained 
on a single 
MULTIMODULE 
board, for high density 
and low cost per channel. 
High quality 
analog 
components 
pro- 
vide 12 bit resolution, 
11 bit accuracy, 
and slew rates per channel 
of 0.1 volt per microsecond. 
Program- 
ming the iSBX 328 MUL T1MODULE board is done via a simple 
two byte protocol 
over the iSBX bus. Max- 
imum channel 
update 
rates are 5KHZ on a single 
channel 
to 1 KHZ on all eight 
channels. 
Outputs 
are 
compatable 
for screw termination 
of field wiring 
on the iCS 910 Analog 
Signal 
ConditioninglTermination 
Panel. 


The 
iSBX 
328 MULTIMODULE 
board, 
shown 
in 
figure 
1 is designed 
to plug onto 
any host 
iSBC 
microcomputer 
that contains 
an iSBX bus connec- 
tor. The board uses an 8041 UPI device to control 
eight 
analog 
output 
channels 
that 
may be user- 
configured 
through 
jumpers 
to operate 
in either 
bipolar 
voltage 
output 
mode 
(- 
5 to 
+ 5 volts), 
unipolar 
voltage 
output 
mode 
(0 to + 5 volts), 
or 
current 
loop 
output 
mode 
(4 to 20 mAl 
applica- 
tions. 
Channels 
may 
be 
individually 
wired 
for 
simultaneous 
operation 
in both current 
loop out- 
put and voltage 
output 
applications. 
The outputs 
from 
50-pin 
edge 
connector 
J1 
on 
the 
MULTI- 
MODULE 
board 
are pin-compatible 
with 
the 
iCS 
910 Signal 
Conditioning/Termination 
Panel. 


Interfacing 
Through the Intel iSBX Bus 


All data to be output 
through 
the MULTIMODULE 
board 
is transferred 
from 
the 
host 
iSBC 
micro- 
computer 
to 
the 
MUL TIMODULE 
board 
via 
the 
iSBX bus connector. 
The UPI device on the MUL TI- 
MODULE 
board 
accepts 
the 
binary 
digital 
data 
and generates 
a 12-bit data word forthe 
Digital-to- 
Analog 
Converter 
(DAC) and 
a four 
bit 
channel 
decode/enable 
for selecting 
the output 
channel. 


The DAC transforms 
the data 
into 
analog 
signal 
outputs 
for either 
voltage 
output 
mode or current 
loop output 
mode. Offsetting 
of the DAC voltage 
in current 
output 
mode may be performed 
by the 
UPI software 
offset 
routine 
or by the hardware 
off- 
set adjustments 
included 
on the board. The MUL- 
TIMODULE 
board status 
is available 
via the iSBX 


bus connector, 
to determine 
if the UPI is ready to 
receive 
updates 
to analog 
output 
channels. 


The 
host 
iSBC 
microcomputer 
addresses 
the 
MULTIMODULE 
board by executing 
IN or OUT in- 


structions 
specifying 
the 
iSBX 
328 
MULTI- 
MODULE 
as a port address. 
The UPI on the iSBX 
328 is initialized 
to 
select 
whether 
software 
or 
hardware 
offset 
is to be used and how many chan- 
nels will 
be active. 
Then a 2 byte transfer 
to each 
active 
channel 
sets 
the 
12 bit 
output 
value, 
the 
channel 
selected 
and the current 
or voltage 
mode. 


Commands 


OUTput 
Command 
- 


7 


NN: 0,0 = unipolar configuration 
software current ollset 
0,1 = no mixing 
1,0 = bipolar configuration 


A 
software current ollset 


last channel 
to be output 


OUTput 
Command 
- 
Data Bytes 
7 


High Byte 


Low Byte 


DAC Data 


o = UPI generates offset 
1 = SBC generates offset 
in current loop mode 


BUFFER 
AMPLIFIER 
6~ 
V~~~AR~~iO 


} 


ANALOG 
OUTPUT 
8 CHANNEL 


J1 


DIGITAL·TO 
ANALOG 
CONVERTER 
12·81T 
RESOLUTION 


ANALOG 
OUTPUT 
MULTI· 
PlEXER 


Interrupts 


No interrupts are issued from the iSBX 328 to the 
host iSBC microcomputer. Data coordination 
is 


handled via iSBC software polls of the status 
buffer. 


Outputs - 8 
non-isolated 
channels, 
each 
in- 


dependently jumpered for voltage output or cur- 
rent loop output mode. 


Voltage Ranges- 0 to + 5 volts (unipolar opera- 
tion) 
- 5 to + 5 volts (bipolar operation) 


Current Loop Range-4 
to 20 mA (unipolar opera- 
tion only) 


Output 
Current- 
±5 
mA 
maximum 
(voltage 


mode-bipolar operation) 


Load Resistance - 0 to 250 ohms with on-board 
iSBX power. 1000 ohms minimum with 30 VDC 
max. external supply 


Compliance Voltage-12 
V using on-board iSBX 


power. If supplied by user, up to 30 VDC max 


Resolution -12 bits bipolar or unipolar 


Slew Rate-0.1 
volt per microsecond minimum 


Single Channel 
Update Rate- 5KHz 


Eight Channel 
Update Rate-1 KHz 


Accuracy- 


Mode 
Accuracy 
Ambient 
Temp 


Voltage-Unipolar, 
typical 
:to.025% 
FSR 
@25·C 


Voltage-Unipolar, 
maximum 
:to.035% 
FSR 
@25·C 


Voltage·Unipolar, 
typical 
:to,08% 
FSR 
@ O· to 60·C 


Voltage·Unipolar, 
maximum 
:to.19% 
FSR 
@ O· to 60·C 


Voltage-Bipolar, 
typical 
:to.025% 
FSR 
@ 25·C 


Voltage-Bipolar, 
maximum 
:to.035% 
FSR 
@25·C 


Voltage-Bipolar, 
typical 
:to.09% 
FSR 
@ O· to 60·C 


Voltage-Bipolar, 
maximum 
:to.17% 
FSR 
@ 0"t060·C 


Current Loop, typical 
:to.07% 
FSR 
@25·C 


Current Loop, maximum 
:to.08% 
FSR 
@ 25·C 


Current Loop, typical 
:to.17% 
FSR 
@0"t060·C 


Current Loop, maximum 
:to.37% 
FSR 
@ 0·t060·C 


Refresh and Throughput Rates" 


Refresh 1channel (no new data): 


Refresh all 8 channeis (no new data): 


Update and refresh 1 channel with new 
data: firmware program 2 
for each additional channel 


Update and refresh 1 channel with new 
data: firmware program 1 or 3 
for each additional channel 


Update and refresh all 8 channels 
(all new data): firmware program 2 
per channel of new data 


Update and refresh all 8 channels 
(all new data): firmware program 1 or 3 


per channel of new data 


80 us 


650 us 


Output Impedance-0.1 
ohm. Drives capacitive 


loads up to 0.05 microfarads. (approx, 1000 foot 
cable) 


Temperature Coefficient - 0.005%/oC 


Interface 
Pins 
Centers 
Mating 


(Qty) 
in 
em 
Connectors 


iSBC 
iSBX 


P1 iSBX 
Bus 
36 
0.1 
0.254 
connector 


J18/16 
3m 3415-000 
or 
channels 
50 
0.1 
0.254 
T1 H312125or 


analog 
iCS 910 cable 


Height - 
1.4cm (0.56inch) MULTIMODULEboard 
only 
2,82 cm (1.13 inches) MULTIMODULE 
and iSBC board. 


Vdd = 
± 12 volts (± 0.6V), Idd = 45 ma max 
(voltage mode) 


= 200 ma max 


(current loop 
mode) 


Environmental 
Characteristics 


Operating Temperatur.e - 
0 ° to 60·C (32° to 


140°C) 


Relative 
Humidity-to 
90% (without 
condensa- 


tion) 


Reference Manuals 


142914·002 - 
iSBX 328 Analog 
Output 
MULTI- 
MODULE 
Board 
Hardware 
Reference 
Manual 
(NOT SUPPLIED) 


Manuals 
may be ordered 
from 
any Intel 
sales 


representative, 
distributor 
office 
or from 
Intel 
Literature Department, 3065 Bowers Avenue, San- 
ta Clara, California 95051 


Part Number 
SBX 328 


Description 
Analog Output MULTIMODULE 
Board 


iSBX 311 


ANALOG 
INPUT MUL TIMODULE 
BOARD 


• Low cost analog input for iSBX MULTI· 


MODULE compatible 
iSBC boards 


• 8 differential/16 
single·ended, fault 


protected inputs 


• 20 mV to 5V full scale input range, 
resistor gain selectable 


• Unipolar (0 to + 5V) or bipolar ( - 5V to 


+ 5V) input, jumper selectable 


• 12·bit resolution analog·to·digital 
converter 


• 0.035% full scale accuracy (11 bits) at 


25°C 


• 18 kHz samples per second through· 


put to memory 


• Connector compatible with iCS 910 


Analog Termination 
Panel 


The Intel iSBX 311 Analog 
Input MUL TIMODULE 
board provides simple 
interfacing 
of non-isolated 
analog 
signals 
to any iSBC board which 
has an iSBX compatible 
bus and connectors. 
The single-wide 
iSBX 311 
plugs directly 
onto the iSBC board, providing 
data acquisition 
of analog signals 
from eight differential 
or 
sixteen 
single-ended 
voltage 
inputs, 
jumper 
selectable. 
The iSBX 311 MUL TIMODULE 
is connector 
and 
pinout 
compatible 
with the Intel iCS 910 Analog 
Signal Conditioning/Termination 
panel so that field wir- 


ing can easily be terminated 
and current 
loop-to-voltage 
conversion 
resistors 
can be mounted 
for current 
loop analog 
signal 
monitoring. 
Resistor 
gain selection 
is provided 
for both 
low level (20mv full 
scale 
range) and high level (5 volt FSR) signals. 
Incorporating 
the latest high quality 
IC components, 
the iSBX 
311 MUL TIMODULE 
board provides 
12 bit resolution, 
11 bit accuracy, 
and a simple 
programming 
inter- 
face, all on a low cost iSBX MULTIMODULE 
board. 


FUNCTIONAL 
DESCRIPTION 


The iSBX 311 Analog 
Input 
MUL TIMODULE 
board 


is 
a 
member 
of 
Intel's 
growing 
family 
of 


MUL TIMODULE 
expansion 
boards, 
designed 
to 


allow 
quick, 
easy, and inexpensive 
expansion 
for 


the Intel single 
board computer 
product 
line. The 


iSBX 
311 
Analog 
Input 
MUL TIMODULE 
Board 


shown 
in figure 
1, is designed 
to plug onto 
any 


host 
iSBC microcomputer 
that 
contains 
an iSBX 


bus connector 
(P1). The board provides 
8 differen- 


tial or 16 single-ended 
analog 
input channels 
that 


may 
be 
jumper-selected 
as 
the 
application 


requires. 
The 
MULTIMODULE 
board 
includes 
a 


user-configurable 
gain, 
and 
a 
user-selectable 


voltage 
input 
range (0 to + 5 volts, 
or 
- 5 to + 5 


volts). 
The 
MULTI MODULE 
board 
receives 
all 


power 
and control 
signals 
through 
the iSBX bus 


connector 
to 
initiate 
channel 
selection, 
sample 


and hold operation, 
and analog-to-digital 
conver- 
sion. 


Input Capacity 


Sixteen 
separate 
analog 
signals 
may be randomly 


. or 
sequentially 
sampled 
in 
single-ended 
mode 


with the sixteen 
input multiplexers 
and a common 


HIGH 


IMPEDANCE 


BUFFER 


AMP 


8 CHANNel 
INPUT 
MULTI· 
PLEXER 


GAIN 
SELeCT• 
OFFSET 
ADJUST 


SIGNAL 
ANALOG 
GROUND 
INPUT 
SIGNALS 


8 CHANNEL 


INPUT 
MULTI. 
PlEXER 


ground. 
For noisier 
environments, 
differential 
in- 
put mode can be configured 
to achieve 8 separate 


differential 
signal 
inputs, or 16 pseudo-differential 
inputs. 


Resolution 


The 
iSBX 
311 
MULTIMODULES 
provide 
12-bit 


resolution 
with 
a 
successive 
approximation 


analog-to-digital 
converter. 
For bipolar 
operation 


(- 
5 to + 5 volts) 
it provides 
11 bits plus sign. 


The 
A-to-D 
converter 
conversion 
speed 
is 
35 


microseconds 
(28KHZ samples 
per second). 
Com- 


bined with the sample and hold, settling 
times and 


the programming 
interface, 
maximum 
throughput 


via 
the 
iSBX 
bus 
and 
into 
memory 
will 
be 54 


microseconds 
per sample, 
or 18 KHZ samples 
per 


second, 
for a single 
channel, 
a random channel, 
or 


a sequential 
channel 
scan. A-to-D conversion 
is in- 


itiated 
via the 
iSBX connector 
and programmed 


command 
from the iSBC base board. Interrupt 
on 


end-of-conversion 
is a standard 
feature 
to ease 


programming 
and timing 
constraints. 


SAMPLE• 
HOLD 
AMP 


START 
CONVERSION 
AND 


CHANNEL 
SelECTOR 
LOGIC 


High quality 
components 
are used to achieve 
12 


bits 
resolution 
and accuracy 
of .035% 
full 
scale 


range ± V2 LSB. Offset 
and gain are adjustable 
to 
± 0.024 % 
FSR 
± 1/2 
LSB accuracy 
at any fixed 
temperature 
between 
OOG(gain 
= 1). See specifi- 
cations 
for other 
gain accuracies. 


To allow 
sampling 
of millivolt 
level signals 
such 


as strain gauges and thermocouples, 
gain is made 


configurable 
via user inserted 
gain resistors 
up to 


250 x 
(20 millivolts, 
full 
scale 
input 
range). User 


can select 
any other 
gain range from 
1 to 250 to 


match 
his application. 


The-host 
iSBG microcomputer 
addresses 
the iSBX 
311 MUL TIMODULE 
board by executing 
IN or OUT 


instructions 
to the 
iSBX 311 MUL TIMODULE 
as 


one of the legal port addresses. 
Analog-to-digital 


conversions 
can be programmed 
in either 
of two 


modes: 1. start conversion 
and poll for end-of-con- 
version 
(EOG), or 2. start conversion 
and wait for 


interrupt 
(INTRO/) 
at end 
of 
conversion. 
When 


conversion 
is complete 
as signaled 
by one of the 


above 
techniques, 
INput 
instructions 
read 
two 


bytes 
(low and high 
bytes) 
containing 
the 12 bit 


data 
word 
plus 
status 
information 
as 
shown 


below. 


OUTput 
Command 
- 
Select 
input 
channel 
and 


start conversion. 


Bit Position 


Input Channel 


INput Data - 
Read converted 
data and status (low 


byte) or Read converted 
data (high 
byte). 
Reads 


can be with 
or without 
reset of interrupt 
request 


line (INTRO/). 


Bit Position 


Low/status Byte 


Fastest 
data conversion 
and transfer 
to memory 
can be obtained 
by dedicating 
the microcomputer 


to 
setting 
the 
channel 
address/starting 
conver- 


sion, polling 
the status 
byte for EOG/, and when it 
comes 
true, read the two bytes of the conversion 


and send 
the 
start 
conversion/next 
channel 
ad- 


dress 
command. 
For 
multitasking 
situations 
it 


may 
be 
more 
convenient 
to 
use 
the 
interrupt 


mode, 
reading 
in data only after 
an interrupt 
sig- 


nals end of conversion. 


Inputs 
- 
8 differential. 
16 single-ended. 
Jumper 


selectable. 


Full Scale Input 
Voltage 
Range - 
- 5 to + 5 volts 
(bipolar). 
0 to 
+ 5 volts (unipolar). 
Jumper 
selectable. 


Gain - 
User-configurable 
through 
installation 
of 
two 
resistors. 
Factory-configured 
for gain of X1; 
gains above 250 not recommended. 


Resolution 
- 
12 bits over full scale range (1.22 mv 
at 0-5 v, 5}Jv at 0-20 mv) 


Gain 
Accuracy 
at 25°C 


1 
± 0.035% ± 
V2 LSB 


5 
± 0.035% ± 
V2 LSB 


50 
± 0.035% ± '/2 LSB 


250 
±0.035% 
± 
V2 LSB 


NOTE: 
Figures are in percent of full scale reading. At any fixed tem- 
perature between 0° and 60°C, the accuracy is adjustable to 
± 0.035% of full scale. 


Gain TC (at Gain = 1): 30 PPM per degree 
centi- 


grade 
(typical); 
56 PPM 
per 
degree 
centigrade 
(max). 


Gain 
Offset 


1 
.0018 


5 
.0036 


50 
.024 


250 
.116 


Common 
Mode 
Rejection 
Ratio 
- 
60 db (mini· 


mum). 


Sample 
and hold - 
sample 
time 
15 


microseconds. 


Aperature 
- 
hold aperature 
time: 
120 


nanoseconds. 


Interface 


Pins 
Centers 
Mating 
(Qty) 
in 
cm 
Connectors 


iSBC iSBX 


P1 iSBX Bus 
36 
0.1 
0.254 
connector 


J18/16 
3m 3415-000 or 


channels 
50 
0.1 
0.254 
T1 H312125 or 


analog 
iCS 910 cable 


Width 
- 
9.40 em (3.7 inches) 


Length 
- 
6.35 cm (2.5 inches) 


Height 
- 
2.03 
cm 
(0.80 
inch) 
MULTIMODULE 


board only 


2.82 cm (1.13 inches) 
MULTIMODULE 
and 
iSBC 


board 


Weight 
- 
68.05 gm (2.4 ounces) 


Electrical Characteristics 
(from iSBX con· 


nector) 


Vcc = 
± 5 volts 
(± 0.25V), Icc = 250 mAmax 


Vdd = + 12 volts (± 0.6V), Idd = 50 mAmax 


Vss 
= 
- 12 volts 
(± 0.6V), Iss = 55 mAmax 


Operating 
Temperature 
- 
0 ° to 
60°C 


(32° 
to 
140°C) 


Relative 
Humidity 
- 
to 90% 
(without 
condensation) 


Shock Tested 
At - 
Class 
B Specification 


Reference Manuals 


142913·001 
- 
iSBX 311 Analog 
Input 
MULTIMOD· 


ULE 
Board 
Hardware 
Reference 
Manual 
(NOT 


SUPPLIED) 


Manuals 
may 
be 
ordered 
from 
any 
Intel 
sales 


representative, 
distributor 
office 
or 
from 
Intel 


Literature 
Department, 
3065 Bowers 
Avenue, 
San· 


ta Clara, California 
95051. 


Part Number 
SBX 311 


Description 
Analog 
Input 
MULTIMODULE 
Board 


• MULTIBUS standard 4-slot backplane, 
expandable to 12 slots 


• Vertical board orientation for 


convection cooling 


• 19·inch wide RETMA rack mounting or 
NEMA type backwall mounting 
brackets 


• Submitted for approval as a UL 
recognized component 


• Slide in/out mounting rails for iSBC 
power supplies 
- 
Quick disconnect cabling for 
serviceability 
- 
Your choice of supply 


• All front access serviceability 
- 
iSBC boards 
- 
Power supplies 
- 
Interrupt and reset buttons 
- 
Operation indicators and fuse 


• Recessed mounting space for signal 
conditioning/wire 
termination 
panels 


The 
iCS 80 Industrial 
Chassis 
provides 
industrially 
oriented 
mounting 
space 
for 
Intel single 
board 
computer 
(iSBC) 
products, 
associated 
iSBC 
power 
supplies, 
and 
related 
iCS 9XX analog 
and digital 
signal 
conditioning/termination 
panels. 
The base unit provides 
a 4-slot 
MUL TIBUS 
backplane 
(iSBC 604) with expansion 
space and cabling 
to expand to 


12 MUL TIBUS 
backplane 
slots 
by adding 
additional 
4-slot 
iSBC 
614s as needed 
(up to two). 
All of the 25-plus 
Intel 
MUL TIBUS 
bus-compatible 
iSBC boards can be inserted 
into any oneof 
the 12 slots. 
In addition, 
over 50 products 
from 30 


independent 
manufacturers 
have 
been 
designed 
for 
mounting 
into 
the 
MUL TIBUS 
backplane. 
Full 
MUL T1BUS 


compatibility 
in the iCS 80 chassis 
also allows 
configuration 
of multiple 
single 
board 
computers 
to share system tasks 
through 
communication 
over the bus (through 
multi master 
bus arbitration 
built 
on the multiple 
iSBC processors). 


Self Contained 
Low Cost Controllers 


Small, self contained industrial controllers can be con- 
figured with the 4-slot cardcage and iSBC 635 power 
supply. As shown in Figure 2, this packaging can also 
accommodate the iCS 9XX series signal conditioning/ 
termination panels. 


Or Large Power and Point Counts in a 
Small Package 


At the high end of performance for the iCS 80 chassis, a 
user can build a 12-slot configuration with the Intel iSBC 
640 Power Supply. This iCS 80 chassis can support the 
iSBC 86/12A 16-bit computer with 112K bytes memory 
(96K RAM, 16K ROM),64 differential analog inputs, 180 
digital inputs, 52 isolated digital outputs, and 8 analog 
outputs 
(four current 
loops); in total a 304-channel, 
mixed analog and isolated digital, input and output con- 
troller, large enough for most dedicated applications 
(see Figure 3 for two other examples). 


Engineered 
for Industrial Applications 


The MULTIBUS slots are mounted vertically to improve 
convection cooling and the top, bottom and sides are 
engineered to allow maximum air flow over the boards. 
Four fans are provided as standard to increase air flow, 
allowing users to eliminate or minimize the need for 
supplementary fans or air conditioning. 


Power Supply Flexibility 


To provide a modular base on which to build a variety of 
configurations, no power supply is provided in the iCS 
80 Industrial Chassis. Users choose one of the low cost 
Intel iSBC 635 (14-amp)or iSBC 640(30-amp)power sup- 
plies based on their application. Slide in/out mounting 
rails are provided to match the iSBC 635 and iSBC 640 
supplies, and quick disconnect cabling and connectors 
are provided for rapid service replacement. An AC wiring 
barrier strip allows simple wiring connections for inte- 
gration into larger systems (see Figure 4). 


Industrial 
Rack Mounting 


The chassis mounts directly into 19-inch standard width 
RETMA (Radio-Electronics-Television 
Manufacturers 
Association) 
customer 
provided 
rack. 
Alternately, 
I 


mounting brackets and power cabling access are pro- 
vided for mounting directly on a backwall, such as the 
backwall panel of a NEMA-type (National Electrical 
Manufacturers Association), front-access-only cabinet. 


Front Access Serviceability 


To simplify serviceability, front access is provided for all 
iSBC boards, the power supply, operation 
indicator 
lights, interrupt and reset buttons, and the AC power 
fuse. 


1 
J 


00000000 0 


Typical Small Configuration 


• 8-bit 8088 processor (iSSC 88/40) 
• 4K bytes RAM (8K optional) 
• 2K·16Kbytes E2PROMor 8K·128Kbytes ROM/EPROM 
• 16-64analog inputs 
• 8 analog outputs 
• 8 isolated digital inputs 
• 8 isolated digital outputs 


OR 


• 12 TIL outputs 
• 12 TIL inputs 


Typical Maximum Configuration 


• 16·bit 8086 processor (iSSC 86/30 w/RAM 
MULTIMODULE) 
• 768K bytes RAM (2 - iSSC 056) 
• 128K bytes EPROM (or 16K E2PROM) 
• 240 analog inputs (3 - iSSC 88/40 w/2 ea. iSSX 311) 
• 24 analog voltage outputs 


OR 


• 24 analog current outputs (4-20mAl 
• 72 isolated digital inputs/outputs 
• 144 TIL digital inputs/outputs (2 - iSSC 519s) 


(All iCS 9XX Signal ConditioninglTermination 
Panels are 


not shown) 


Figure 4. Rear View iCS 80 Chassis Showing Power Distribution Panel, and Cabling from ICS 80 Chassis to iCS 9XX 


RETMA Mounted Signal Conditioning Panels (Top of iCS 80 Chassis) 


To assist in development, checkout and service, two 
pushbuttons are provided. The RESETbutton pulls low 
the initialize line (INIT)on the MULTIBUSbackplane. The 
INTERRUPTbutton pulls low one interrupt line on 'he 
MULTIBUSbackplane (INT1).Logic within the iCS 80 en- 
sures that these buttons function with all versions of 
Intel single board computers. From the front of the iCS 
80 chassis, without a CRT or other panel, an operator or 
service person can reset or interrupt on·going iCS 80 
system operations to get attention, signal an alarm, or 
start a self-test operation. 


A front panel key provides three positions: OFF (AC 
power off and key removable), ON (AC power on, push- 
buttons 
enabled, key unremovable), and LOCK (AC 
power on, pushbuttons disabled, key removable). 


Three 
indicator 
light 
emitting 
diodes 
record 
basic 
chassis status. POWER ON (GREEN); RUN (GREEN); 
and HALT (RED);the RESETor INTERRUPTbuttons will 
remove the HALT state. 


U.L. Approved 


The iCS 80 chassis has received full Underwriters Labor- 
atory approval (F.6#E70842)as a U.L. listed component 
under the Underwriters Laboratories Safety Standard for 


Process Control Equipment, UL1092.When installed as 
described in the iCS 80 Installation Manual, the iCS 80 
chassis provides adequate protection 
against shock, 
fire and casualty hazards, and should comply with most 
local and regional requirements for installation 
in or- 
dinary locations. In addition, the iCS 80 chassis was 
designed to comply with the UL requirements for Data 
Processing Equipment, UL478. It has also been submit- 
ted to the Canadian Standards Association and approval 
is pending under CSA category C22.2 No. 142,the Cana- 
dian Standard for Safety for Process Control Equipment 
and C22.2 No. 154 for Data Processing Equipment. 


Mounting 
Space 
for Signal 
Conditioning/Wire 
Terminations 


The cardcages and power supplies in the iCS 80 chassis 
are recessed behind the front edge of the rack mounting 
ears to provide mounting space for the iCS 9XX series 
signal conditioning/termination 
panels and field wiring. 
For smaller systems with only one or two iSBC 604/614 
cardcages (4to 8 slots), up to two iCS 910,iCS 920,or iCS 
930 signal 
conditioning/termination 
panels can be 
mounted vertically over the areawherethe second orthird 
cardcage would mount (see Figure 2). The benefit of this 
design is a completely self-contained industrial chassis 
with iSBC cards, power supply, signal conditioning and 
field wiring terminations, all in one enclosure. 


Capacity 


Four slots for MULTIBUS compatible single board com- 
puters, memory, 1/0 or other expansion boards 
Expandable to 12 slots using customer plug-together 
iSBC 614 cardcages 


Front Panel Controls 


Pushbuttons 
RESET: Connected to Initializel 
on .MULTIBUS back- 
plane 
INTERRUPT: Connected to Interrupt 11 line on MULTI· 
BUS backplane. 


Panel Indicator Lights (LEOs) 
POWER ON (green): + 5V power exists on the MULTI· 
BUS backplane 
RUN (green): CPU is executing an instruction. 
Light 
goes out if CPU is in WAIT or HALT state 
HALT (red): CPU has executed a HALT instruction 


Keylock 
OFF: AC power off, key rem6vable 
ON: AC power on, pushbuttons enabled, key unremov- 
able 
LOCK: AC power on, pushbuttons disabled, key remov- 
able 


Equipment 
Supplied 


iCS 80 industrial chassis,three fans for cardcages,one fan 
for power supply: 
4-slot 
cardcage with 
MULTIBUS 
backplane, control panel with switches, indicators, key- 
lock, power distribution barrier strip, AC power fuse, line 
filter, 115Vpower cable, and logic for interrupt and reset 
buttons. 
An installation 
package 
is also provided, 


including a NEMA cabinet mounting kit, power supply 
extension cables, and RETMA cabinet mounting screws, 
110/230VAC operation. 


Software 


See the RMX/80 Real-time 
Multitasking 
Executive 
specifications 
for 
industrial 
related applications. 
In 
addition, system mon,itors for most of the Intel single 
board computers are available in the INSITE (Intel's 
Software 
Index and Technology 
Exchange) 
User's 
Program Library. 


Physical Characteristics 


Height - 
39.3 em (15.7 in.) 
Width - 
48.5 em (19.0 in.) at front panel 
43.5 em (17.4 in.) behind front panel 
Depth - 
30.0 em (12.0 in.) with all protrusions 
Weight - 
16.8 kg (37.0 Ib) without power supplies 


Environmental 
Characteristics 
(Ambient at iCS-80 air intake, bottom of chassis) 


Temperature (Ambient) 
Operating: O°C to 50°C (32°F to 122°F) 
Non-operating: - 40°C to + 85°C 


Humidity - 
Up to 90% relative, noncondensing at 40°C 


Electrical 
Characteristics 


The iCS 80 chassis provides mounting space for either the 
iSBC 635 
or iSBC 640 
power supply. Unless otherwise 
stated, electrical 
specifications 
apply to both power 
supplies when installed by user in iCS 80 chassis. 


Input 
Power 
Frequency: 47 to 63 Hz. Voltage 
(Nominal) 
(Single Phase): 100, 
115, 
215, 
or 230 
VAC 
+10%, 
jumper 
selectable. 


Current: 
With iSBC635 
With iSBC 640 
Input Voltage 


(Including 
fans) 
3.0A max 
5.6A max 
103 VAC 


1.5A max 
2.8A max 
206 VAC 


Power, max: 
315 watts 
580 watts 


Voltage 
Output 
Current 
(max) 
Overvoltage 
Protection 


iSBC635 
JSBC 640 
iSBC 635 
iSBC 640 


+ 12V 
2.0A 
4.5A 
+ 14V to + 16V 
+ 14V to + 16V 
+5V 
14.0A 
30.0A 
+ 5.8V to + 6.6V 
+ 5.8V to + 6.6V 
-5V 
0.9A 
U5A 
- 5.8V to - 6.6V 
- 5.8V to - 6.6V 
-12V 
0.8A 
U5A 
-14V 
to -16V 
-14V 
to -16V 


Combined 
Line/Load 
Regulation 
- 
±1% 
at ±10% 
static 
line cbange and ±50% 
static load change, measured atthe 
output connector 
(±0.2% 
measured at the power supply 
under the same conditions). 


Remote 
Sensing 
- 
Provided for +5 VDC 
output 
line 
regulation. 


Output 
Ripple 
and Nolse-10 
mV (iSBC 635 and iSBC 640 


Output 
Transient 
Response 
- 
Lessthan 50 I'sec for ±50% 
load change. 


Maximum 
Watts 
Dissipation 
(load plus iosses) - 
500W 
(iSBC 640 supply), 250W 
(iSBC 635 
suppiy) 


Installation 


Complete instructions 
for installation 
are contained in 
the iCS 80 Site Planning and Installation 
Guide, in- 
cluding RETMA and NEMA cabinet mounting, and field 
signal, ground wiring and cooling suggestions. 


Warranty 


The iCS 80 Industrial Chassis is warranted to be free 
from defects in materials and workmanship under nor- 
mal use and service for a period of 90 days from date of 
shipment. 


Reference 
Manuals 
9800799A 
'- 
iCS 80 Industnal Gnassis Hardware Refer- 
ence Manual (SUPPLIES) 
9800798 - 
iCS 80 Industrial Systems Site Planning and 
Installation Guide (SUPPLIED) 


9800708A 
- 
iSBG 604/614 
Cardcage Hardware Refer- 
ence Manual (SUPPLIED) 


Reference manuals are shipped with each product only 
if designated SUPPLIED (see above). Manuals may be 
ordered from any Intel sales representative, distributor 
office or from Intel Literature Department, 3065 
Bowers 
Avenue, Santa Clara, California 
95051. 


The.iCS 80 Industrial Chassis must beordered asakit with 
an Intel power suppiy of your choice. Ordering asa kit will 
ensure shipment of the power supply and iCS 80chassis at 
the same time. Typical 
configurations 
and ordering 
instructions are: 


Part Number 


ICS 80 
Kit 635 
Description 


iCS 80 system consisting of: 
iCS 80 Industrial Chassis 
iSBC 635 
Power Supply 


CS 80 system consisting of: 
CS 80 Industrial Chassis 
SBC 640 
Power Supply 


inter 
APPLICATION 
NOTE 


I. INTRODUCTION 


The introduction 
of the single board computer 
as a 
tool for the system designer has opened the way for 
many varied application 
areas to benefit 
from the 
advantages 
of computer 
utilization. 
A problem 
still 
exists, 
however, 
because 
the available 
I/O 
con- 
figurations 
have been largely incompatible 
with the 
wiring and packaging 
techniquet; required 
in indus- 
trial environments. 
This problem 
is overcome 
by 
the utilization 
of the Intel® iCS™ product family. 
The purpose 
of this application 
note is to provide a 
representative 
approach 
to the implementation 
of a 
computerized 
solution 
to 
an 
industrial 
control 
system. 


System Description 


This 
application 
note 
will 
deal 
with 
a control 
system which will regulate 
the temperature 
in each 
of four ovens. Each oven will be defined 
as utiliz- 
ing a light bulb for heating. 
Normal convection 
will 
be used to provide 
cooling. 
The internal 
tempera- 
ture will be measured 
by means of a thermistor 
in- 
stalled in each oven. We will assume that we will be 
required 
to implement 
some type of operator 
panel 
near the ovens which will allow the status of each 
oven to be monitored. 
This approach 
is similar to 
many 
common 
industrial 
applications 
which 
re- 
quire a supervisory 
control 
station 
in one area and 
a 
separate 
operator 
interaction 
panel 
near 
the 


equipment 
being controlled. 
The setpoint 
and tol- 
erances should be input from an external 
location. 


With these facts about 
our system defined, 
we can 
begin a step by step solution 
to providing 
a com- 
puterized 
control 
system to operate 
the ovens. We 
will discuss 
the various 
equipment 
trade-offs 
and 
the decisions which will be used to define the hard- 
ware/software 
designs. 


Control Algorithm 


Before we can begin the design of our system, 
we 


must have a clear idea of the technique 
we wilLuse 
to control 
the system. 
Our 
control 
system 
must 
maintain 
the oven temperature 
within a predefined 


and 
fairly 
narrow 
range 
of the set point. 
Let us 


make an assumption 
that the light bulb will be con- 
trolled digitally, 
meaning 
that the bulb must either 
be turned 
fully on or it must be turned 
fully off. 


The obvious 
control 
technique 
then becomes 
turn- 
ing the bulb on when the temperature 
of the oven is 


below 
our 
lower 
limit 
and 
turning 
the bulb 
off 
when the temperature 
is above the higher limit. It 
seems reasonable 
to assume that this technique 
will 
provide 
a temperature 
in the oven 
which 
varies 


sinusoidally 
with time. 
This is true because 
even 
though 
the lamp is turned 
off, 
it will continue 
to 
generate 
heat for a short period of time. Likewise, 


when the bulb is turned 
on, it will not instantly 
be 


able to provide 
heat to raise the temperature 
of the 


chamber. 
We would 
expect 
to have a system 
re- 


sponse 
such 
as is shown 
in Figure 
). 
A better 


method 
of control 
can be devised 
if we provide 
some type of temperature 
prediction 
into our con- 


trol 
algorithm. 
Since 
this 
utilizes 
the 
rate 
of 


temperature 
increase 
or decrease, 
it will involve a 
type of derivative 
control 
system. 
This derivative 
control 
action will tend to dampen 
the temperature 
oscillations 
which might be encountered 
if only an 


instantaneous 
on-off 
control 
system were utilized. 
Figure 
2 shows 
the response 
with 
time 
that 
we 
might expect with this type of control 
system. 


The 
second 
approach 
is 
superior 
to 
the 
first 


because 
the control 
will provide 
a much 
smaller 
oscillation 
of the oven 
temperature. 
Other 
solu- 
tions are possible, 
such as providing 
a modulated 


output 
to the lamp. However, 
in an attempt 
to pro- 


vide a simple 
model 
upon 
which 
to expand 
our 
system solution, 
we will assume that the second ap- 
proach 
will provide 
us with an accurate 
enough 


control 
of the oven temperature. 


Having 
made the decision 
as to the control 
tech- 
nique, we can proceed with the task of determining 
the general 
system configuration. 
That 
is, we can 
define 
the physical 
system characteristics 
and the 
components 
to which we must interface 
the com- 
puter 
system. 
This 
approach 
is identical 
to that 
which 
would 
be used 
in a conventional 
control 
system design. 


Basic System Configuration 


Based upon 
the data 
which we have provided 
so 
far, it is possible 
to build a block diagram 
of the 
system's 
major 
components. 
The system 
consists 
of four ovens, 
an operator's 
panel, 
a data 
entry 


panel, 
and 
the actual 
control 
logic. A block 
dia- 


gram for the system is shown in Figure 3. We must 
now 
further 
define 
the elements 
which 
make 
up 
each of these blocks. 


Each oven must consist of a heating element, 
which 


we have already defined as being a light bulb, and a 
temperature 
sensing 
element 
which 
we have said 


will be a thermistor. 
Each heating 
element 
will be 
switched 
on 
or off 
by applying 
or 
removing 
a 
source 
of )) 5 VAC. 
The thermistor 
temperature 
can be sensed by using the thermistor 
in a voltage 


divider 
circuit. 
We can then measure 
the voltage 


across 
a fixed resistor 
to obtain 
an analog 
signal 


which is proportional 
to the oven temperature. 
We 


will determine 
the 
required 
value 
of 
the 
fixed 


resistor 
at a later time. 


The operator's 
panel should be designed to provide 


the work floor operator 
with basic information 
as 
to the status 
of each 
oven. 
It should 
also allow 


some method 
by which he can inhibit the operation 


of any oven should 
it become necessary 
for charg- 


ing or servicing 
the oven. 
We can then define 
the 


basic elements 
which should 
make 
up the opera- 


tor's control 
panel. 
Each oven should 
have associ- 


ated with it the following 
controls 
and indicators: 


I. Oven ON/OFF 
Switch - 
This switch will allow 


the operator 
to inhibit 
the oven operation 
by 


turning 
the appropriate 
oven switch to OFF. 


2. Oven 
RUNNING 
Indicator 
- 
This 
indicator 


will provide 
a visual indication 
that the oven is 
activated 
and that the temperature 
is being con- 


trolled. 


3. Oven IN TOLERANCE 
Indicator 
- 
This indi- 


cator 
will turn 
on when the oven temperature 


falls within the allowable 
bandwidth 
around 
the 


setpoint 
for that oven. 


4. Oven ALARM 
Indicator 
- 
This indicator 
is the 


complement 
of the in tolerance 
lamp. 
It will be 


turned 
on when 
the oven is activated 
and the 
temperature 
does 
not 
lie within 
the 
desired 


bandwidth. 


5. Oven CAUTION 
Indicator 
- 
It may be neces- 


sary to alert 
the operator 
to a potential 
oven 


temperature 
control 
problem 
before 
it actually 
occurs and sets off the alarm indicator. 
Since we 


have defined our control algorithm 
as utilizing a 
type of derivative 
control, 
we can project 
the 
oven temperature 
ahead 
in time. 
We will turn 


the oven caution 
indicator 
on when we predict 


that the oven temperature 
will lie outside of the 


desired 
bandwidth 
in a predetermined 
future 


time period. 


We have now defined 
the operator 
interface 
which 


we will utilize 
to control 
and 
monitor 
the oven 


processes. 


At this point, 
we will make a decision 
that the in- 


terface 
used 
to input 
the setpoints 
will utilize 
a 


CRT terminal. 
Though 
the decision may seem to be 


completely 
arbitrary, 
we will see later that CRT ter- 


minals 
provide 
an 
extremely 
useful 
device 
for 


allowing an operator 
to communicate 
with the sys- 


tem. Once the decision has been made, we have no 


further 
requirements 
to consider 
hardware 
design 
for this terminal, 
as the entire 
operation 
can 
be 


handled 
in the software 
development 
which will be 
considered 
later. 


A common 
technique 
for documenting 
a system is 


the ladder diagram. 
At this time, we can construct 
a ladder 
for our control 
system. 
Unlike 
conven- 


tional design techniques, 
our ladder 
diagram 
need 


only be concerned 
with the actual drive and sensing 
circuits since the logic required 
to drive the various 


outputs 
will be defined using software. 
This results 


in a considerable 
simplification 
of the design pro- 
cess. A ladder diagram 
for a typical oven is shown 


in Figure 4. We can defer 
the implementation 
of 


the.control 
algorithm 
until we begin to develop the 
software 
portion 
of our control 
system. 
It is now 


possible 
to complete 
the external 
hardware 
design 


and to implement 
the system wiring package. 


15 
N 


OV1 
EAO 


"ON" 


ON1 
E94 
21 
B 


TOll 
E80 


"IN TOL" 


22 
G 


CTN1 
E84 


"CAUTION" 


23 


ALR1 
EgO 


"ALARM" 


2. 


QVN1 
HEATER 
EA' 
25 


15 
10_(WIRE 
LABELS) 
N 


II. WIRING INTERFACES 


A major 
pitfall in utilizing a computer 
for control 
systems has traditionally 
been the requirement 
for 


the 
design 
engineer 
to 
expend 
a 
considerable 
amount 
of his time in designing 
interfaces 
to con- 


nect the physical 
wiring 
to the computer 
system. 


The introduction 
of Intel's product 
line of termina- 
tion panels 
has essentially 
eliminated 
the require- 


ment of designing 
interfaces 
and allows more engi- 
neering time to be spent providing 
a solution 
to the 
application. 
Before 
we continue 
with the specific 
design, 
we should 
spend some time discussing 
the 
various 
types of termination 
panels 
available 
and 


the general 
characteristics 
of each panel. 


Analog Termination 
Panels 


The 
Intel' 
iCS 9101\1 Analog 
Termination 
Panel 


has been designed to provide a simple means of ter- 
minating 
the analog 
wiring 
and 
of providing 
an 


interface 
to the control 
system 
input/output. 
All 
wiring 
is terminated 
utilizing 
pressure 
type screw 
barrier 
blocks. 
Termination 
blocks have been pro- 
vided to allow the termination 
of up to 32 single- 
ended or 16 differential 
channels 
of analog 
input. 


For use in a differential 
input environment, 
such as 
we will be using, the terminator 
blocks provide wir- 
ing terminations 
compatible 
with shielded cable in- 


puts in that provision 
has been made to accept the 


shield of each input signal. The shield is then car- 
ried through 
the on-board 
circuits to the analog-to- 
digital converter. 
Provision 
has been made on the 
board 
for the mounting 
of commonly 
used circuits 
for signal conditioning. 
The available 
signal condi- 


tioning 
circuits 
provide 
for installation 
of current 


termination 
resistors and the installation 
of a single 


pole 
low pass 
filter 
network. 
The 
basic 
barrier 


assignments 
for the iCS 910 termination 
panel are 
shown 
in Figure 
5. The possible 
circuit 
networks 
for this panel are illustrated 
in Figure 
6. A com- 


plete description 
of the analog 
termination 
panel 
can be found in the iCS 910 Analog Signal Condi- 
tioning/Termination 
Panel Hardware Reference 


Manual (manual 
order number 
9800800A). 


The functions 
of the analog 
termination 
panel will 
become more clear as we develop the actual config- 
uration 
required 
to suppor! 
our oven application. 


Referring 
to the ladder 
diagram 
(Figure 4) we see 


that a fixed resistor is necessary to provide the volt- 
age divider network 
to sense the oven temperature. 


The 
current 
termination 
resistor 
(Rc) 
on 
the 
iCS 910 board can be used to provide a convenient 
mounting 
location 
for 
this component 
(refer 
to 


iCS 910 circuit schematic, 
Figure 6). At this point, 
we must make a design decision 
regarding 
the uti- 
lization of a low pass filter for our analog circuits. 
Since the oven temperatures 
are not expected to ex- 


hibit rapid fluctuations 
with time, the use of a low 


pass filter will not adversely effect the temperature 
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sensing. 
Indeed, 
the use of a low pass filter should 


contribute 
to spurious 
signal rejection 
should 
the 


analog cables pick up external 
noise signals. Calcu- 


lations 
will show that 
the use of a filter network 


consisting 
of 11K ohm series resistors 
and a 2.2 I-'F 


capacitor 
will 
provide 
the 
filter 
characteristics 


shown in Figure 7. 
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Based upon our requirements 
and using the circuit 


schematic 
of Figure 
6, we can provide 
the circuit 


interfaces 
required 
by our ladder 
diagram 
(Figure 


4) by configuring 
the channels 
of the iCS 910 ter- 


minator 
as shown in Figure 8. This results in a sim- 


ple two-wire per oven analog 
interface. 
The termi- 


nator 
board 
is designed 
to connect 
to the various 


analog 
I/O boards 
by means of a standard 
ribbon 


cable which is supplied 
with the terminator 
panel. 


The 
ac~ual 
selection 
of 
the 
appropriate 
analog 


board 
will be deferred 
until later. 
We will define 


that oven number 
1 will correspond 
to the differen- 
tial analog 
channel 
0; oven 2 will correspond 
with 


channell; 
oven 3 will correspond 
with channel 
2; 


and oven 4 will use channel 3. This leaves 12 analog 
differential 
channels 
available 
for 
future 
expan- 


sion. The channel 
selection just made was a purely 


arbitrary 
choice. 


The 
wiring 
to the iCS 910 terminator 
panel 
can 


then 
be made 
essentially 
as shown 
in Figure 
9. 
Clearly, 
the use of the ttrminator 
panel 
greatly 


simplified 
the connection 
between 
the control 
sys- 
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tem and the physical devices which are to be moni- 
tored or controlled. 
Figure 10 shows the placement 


of the components 
onto 
the board. 


Low Voltage Digital Termination 
Panels 


Looking 
again at our ladder 
diagram 
for an oven 


control 
system (Figure 4), we see the need to pro- 


vide a second 
type of interface 
signal. 
This is to 
provide 
the 
switching 
for 
the 
various 
indicator 
lamps used on the operator's 
control 
panel. Tradi- 


tionally, 
this interface 
has been handled 
by using 
electromechanical 
relays. The coils would be driven 
by the low voltage 
control 
system 
and 
the relay 
contacts 
were used to drive the external indicators. 
Modern 
technology 
provides 
us with a solid state 
device to perform 
the same function, 
the optical 
isolator. 
We can 
use these 
devices 
to provide 
a 


highly reliably and low cost alternative 
to the relay 


interface. 
The Intel'" 
iCS 9201\1Digital Signal Con- 


ditioning/Terminator 
Panel 
provides 
us with 
a 
convenient 
vehicle 
for 
mounting 
the 
optical 


isolator 
circuits 
and 
for 
terminating 
the 
wiring 
associated 
with the indicator 
devices. 


The iCS 920 panel is designed 
to be used by those 
interface 
circuits which incorporate 
operating 
volt- 


ages less than 50 volts and which. generally 
use cur- 
rents which are smaller than 300 mA. These limits 
are given only for a general guideline 
since a wide 
variety of optical isolators 
and drivers are available 
for 
use on the 
board. 
Some 
of the devices 
are 
capable 
of handling 
greater voltages or currents. 
A 
representative 
list of available 
devices 
and 
com- 


plete details of the termination 
panel are available 


in the iCS 920 Digital Signal Conditioning/Termi- 
nation Panel Hardware 
Reference 
Manual 
(manual 


order number 
980080IA). 


The digital 
panel providcs 
terminations 
for up to 


24 digital 
channels, 
each 
of which 
can 
be con- 


figured as either an input or an output 
channel 
ac- 
cording 
to the specific 
application 
requirements. 
As with the analog 
termination 
panel, 
all wire ter- 
minations 
are 
made 
using 
pressure 
type 
barrier 
strips which will accept up to 16 gauge wire. The 24 
digital 
channels 
correspond 
with those input/out- 


put channels 
assigned 
to the standard 
Intel 
I/O 
configurations 
used on the single board computers 
and 
I/O expansion 
boards. 
We will dwell more on 


this 
subject 
later 
when 
we define 
the 
addresses 
associated 
with each circuit which we desire to in- 
corporate 
into the termination 
panel. 


Since the digital 
channels 
can be configured 
into 
either an input or an output 
mode, it is wise to dis- 
cuss each configuration 
so that a clear understand- 
ing of the board can be obtained, 
even though 
our 
application 
example will only use the output 
mode 
with this board. 


Figur.e II provides a schematic 
of the panel when it 


is configured 
for a digital input mode. To set up a 
channel 
to operate 
as an input, 
it is necessary 
to 
add at least two jumpers 
to the wire-wrap 
jumper 


posts. 
As can be seen, pins 6 and 4 must be con- 


nected together 
as well as pins 3 and 5. If the board, 


is to provide a visual LED indication 
of the channel 
status, 
an additional 
jumper 
should 
be installed 


between pins I and 2 of the jumper 
posts. If this is 


done, be certain to take into account 
the additional 


current 
requirements 
when calculating 
the required 


input 
resistors. 
Two 
resistor 
mounting 
'locations 


are provided 
to allow installation 
of selected com- 


ponents 
to handle 
the current 
limit 
through 
the 


optical 
isolator 
(Rx) a'nd the threshold 
voltage 
for 


turn-on 
of the device 
(Ry). 
A complete 
and 
de- 


tailed procedure 
for selecting 
these resistors 
based 


upon the input voltages is provided 
in the iCS 920 


hardware 
reference 
manual mentioned 
earlier. 
Pro- 
vision has also been made on the termination 
panel 


for 
the 
installation 
of a diode 
(CR) 
to protect 
against 
reverse bias application. 


The components 
have been placed on the board ar- 


ranged 
in groups 
of two channels. 
This eases the 
task of finding 
various 
components 
or of locating 


the holes for installing 
the required 
components. 


This layout 
is illustrated 
in Figure 
12, It is impor- 


tant to take note of the physical 
placement 
of the 


optical 
isolator 
chips in the 20-pin socket. 
This in- 
stallation 
location 
must 
be 
followed 
rigorously 


when using a channel 
in an input mode. 
Also take 


note that provisions 
are provided 
for mounting 
t\VO 
sizes of resistors 
in location 
(Rx). This will accom- 


modate 
the power dissipation 
requirements 
which 


will be encountered 
in various 
application 
situa- 
tions. 
Referring 
again 
to Figure 
12, note that the 
upper 
half of the layout 
represents 
odd channels 
and the lower portion 
of the layout is used for even 


channel 
component 
mounting. 


Figure 
11. 
iCS 920™ 
Digital 
Terminator 
Input 


Configuration 


When the iCS 920 panel is used in this input mode, 
it corresponds 
lo the utilization 
of a relay coil to 


sense some external 
contacl 
closure. 
The resistors 
can be thought 
of as selecting the coil's operating 
voltage 
and the diode 
provides 
the same transient 


protection 
function 
as when installed 
on an electro- 


mechanical 
relay. Finally, 
the optical 
isolator 
out- 
put corresponds 
to the contacts 
associated 
with the 


relay coil. As we will see later, 
this approach 
pro- 


vides us with an unlimited 
number 
of contacts 
per 


relay coil. 


The oven application 
requires a contact 
for driving 


the indicator 
lamps associated 
with each oven. 
If 
we define the driving voltage to be 24 volts DC, we 
will find that the voltage and current 
requirements 


fall within the limits specified for using the iCS 920 
Digital 
Signal 
Conditioning/Termination 
Panel. 


Let us examine 
in more detail how this can be ac- 


complished. 


We 
will select 
an 
industrial 
indicator 
assembly 


which utilizes a full voltage 
24-voll lamp. 
Typical 


lamps would be type 387. This will require a drive 
of 40 mA at 28 volts. Our switching device must be 
capable 
of driving 
this 
load. 
The 
analogy 
used 


earlier to compare 
the optical isolator 
with a relay 


in an input 
mode 
holds 
true when we utilize 
the 


devices in an output 
configuration. 
If we examine 


the data sheet for the current 
switching 
character- 


istics of a typical optical 
isolator, 
say the T1L 113 


(Appendix 
A), we can see that the current and volt- 


age 
requirements 
fall 
well within 
the 
allowable 


ratings 
of the device. 
We have selected 
the relay 


contact 
characteristics! 
We need not concern 
our- 


selves 
with 
the 
selection 
of 
current 
limitation 


resistors 
(coil voltage ratings) since this circuitry 
is 


provided 
on the terminator 
panel when a circuit is 


0 
0 


0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 


configured 
in an output 
mode. If we refer to Figure 
13, we can see the on-board 
schematic 
for the out- 
put drive mode of operation. 
Two jumpers 
must be 
installed 
for each 
output 
channel. 
The 
first, 
be- 
tween pins 1 and 2, is used to enable the LED chan- 
nel status 
indicator. 
The second, 
between 
pins 3 


and 4, actually 
connects 
the computer 
generated 
drive 
signal 
to the 
input 
of the optical 
isolator 
(analogous 
to connecting 
the relay coil to the driv- 


ing line). Provision 
has been made on the circuit 
board 
for only one optional 
component 
in the out- 
put mode; this is the resistor (Rz). This component 
has the effect of increasing 
the response time of the 


switching 
device. 
Because our indicator 
lamps are 
not time critical, 
we will choose to omit the instal- 
lation 
of this component. 


Figure 
14 provides 
a drawing 
showing 
the location 
of the components 
on the iCS 920 panel when it is 
utilized as an output 
switch. Again note the place- 


ment of the optical 
isolators 
in the 20-pin sockets. 


Also note the jumper 
arrangement 
used to provide 


the required 
output 
circuitry. 


Again referring 
to Figure 
13, we see that an alter- 
native 
to using 
the optical 
isolator 
for a switch 
exists. 
Provision 
has been made 
on the panel 
for 
the installation 
of high power 
buffer/driver 
chips 


such a~ the TI 75462. This device provides 
the same 


coil/contact 
characteristics 
as our optical 
isolator; 


however, 
no isolation 
between 
the input and out- 
put is provided. 
In certain 
applications, 
this con- 
figuration 
may 
be desirable 
and 
can 
be imple- 
mented 
by connecting 
jumpers 
1 and 3 together, 


then placing a jumper 
block in the isolator 
socket 


location. 
The 
oven 
application 
will not 
use this 


mode because of the many advantages 
which isola- 
tion can provide. 


Prior 
to actually 
installing 
the components 
onto 


the iCS 920 panel, 
it is necessary 
to assign 
the 


lamps to definite 
channel 
addresses. 
This involves 


making 
some 
additional 
assumptions 
and 
design 
configuration 
decisions. 
If we consider 
the total 
number 
of digital inputs and outputs 
which are re- 
quired to handle all four ovens (including 
the as yet 


unconsidered 
switch 
and 
heater 
signals), 
we see 


that a total of 24 channels 
will be required. 
These 


will be broken 
out as shown below: 


No. of 
Channels 


16 
4 
4 


Type 
DC 
AC 
AC 


Function 


Oven indicator 
lamps 


Oven heaters 
Oven RUN switches 


G--CKJ--8 
G----C§D---8 
G--C::J-B 8 


0 b 
0 
~~~~o 


0 


0 
0 


~Ol""""" 
0 
0 
0 
0 
~ 
0 
0 0 


( 
) 


~ 
0 
0 


~ 
8 


0 2:J 0 
) G--C::J-B 
0 
0 
~~~o 


0 
0 
0 0 
0 


~ 


We have indicated 
that the 16 indicator 
lamps can 
be handled 
using the iCS 920 panel. 
An examina- 
tion of the data sheets for the various 
Intel single 
board computers 
and expansion 
boards provides us 
with the fact that a common 
characteristic 
of most 
boards 
is the use of at least one Intel 8255 Pro- 
grammable 
Peripheral 
Interface. 
This provides 
us 
with at least 24 I/O 
lines with which to work on 
each single board 
computer. 
We can then assume 
that we will not require an I/O expansion 
board to 
implement 
our application. 
Ideally, 
we can handle 
our total requirements 
with one parallel 
interface. 


The various 
Intel parallel 
ports are brought 
off of 
the 
computer 
and 
expansion 
boards 
using 
edge 
connectors. 
These edge connectors 
are then con- 
nected 
to the termination 
panels 
using a standrd 
ribbon cable assembly, 
effectively 
providing 
an ex- 
tension 
of the I/O 
ports 
out 
to the termination 
panels. The 24 channels 
are grouped 
into three I/O 
ports (each consisting 
of 8 channels 
or bits) which 
are then called port A, port B, and port C. When 
connected 
to the iCS 920 panel, 
these ports 
and 
their bit assignments 
will be as shown in Figure IS. 


At this point, 
we seem to be in a dilemma 
since we 
would like to use all 24 channels 
and we have used 
only 16 of them on our panel while we have utilized 
the edge connector 
of the interface. 
It would 
be 
desirable 
to have 
some 
technique 
to extend 
the 
other 
8 channels 
to 
a 
high 
voltage 
terminator 
panel. 
It might 
be well to interrupt 
our channel 
assignments 
at this time to jump 
ahead 
and con- 
sider the features of the iCS product 
line which will 
enable 
us to accomplish 
our interface 
desires. 
We 
will then consider 
the interface 
of the high voltage 
signals 
to our control 
system 
before 
returning 
to 
the 
problcm 
of assigning 
port 
locations 
to our 
lines. 


High Voltage Digital Termination 
Panels 


The 
Intel' 
iCS 930[\1 AC 
Signal 
Conditioning! 


Termination 
Panel is designed to interface 
up to 16 
AC signals (up to 280 volts at 3 amps) or high cur- 
rent DC signals (up to 50 volts at 3 amps) 
to the 
parallel 
ports of the Intel single board 
computers 
or I/O expansion 
modules. 
The barrier 
strip termi- 
nations 
on this panel are designed 
to easily handle 
the 14 gauge wire commonly 
found in applications 
requiring 
the use of the AC terminator. 


Solid state relays are used to provide 
the interface 
between 
the computer 
I/O 
ports and the physical 
plant devices. These devices make the utilization 
of 
the panel a simple task once a ladder 
diagram 
of 
the required 
circuits 
has been drawn. 
As we have 
previously 
mentioned 
and as is clear from looking 
at Figure 4, we shall 
need to utilize eight of the 
available 
circuits, 
four for input and four for out- 
put. 
The 
implementation 
of each 
signal 
type re- 
quires only that we insert the correct 
type of solid 
state relay into the appropriate 
socket. 


First, 
consider 
the 
input 
configuration 
which 
is 
required 
to sense the position 
of the oven 
RUN 
switches. 
Figure 
16 shows 
the circuit 
schematic 
when used in the input mode. 
We can see that the 
output 
signal will turn on when the input power is 


applied. 
Like the digital 
termination 
panel, 
each 
circuit's 
status is indicated 
by means of an LED in- 
dicator 
installed 
on the board. 
The input circuit is 
protected 
by a socketed 
3-amp fuse which may be 
replaced 
without 
the need to solder 
any compo- 
nents. The solid state relay used for this configura- 
tion should be a type lACS which is available 
from 
either 
Opto-22 
or Motorola. 
Complete 
details 
of 
available 
relays 
and 
their 
uses on the board 
are 
available 
in the iCS 930 AC Signal Conditioning/ 


[Jf~11;'~·fJ.;~;~1 
§r~~'~'"l k:i~~r:-D>r,~~j 


3 
7 
6 
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Termination Panel Hardware Reference Manual 
(manual 
order 
number 
9S00S02A). 
Keep in mind 
the fact that although 
this application 
note repre- 


sents the solid state relays as being actual relays and 
contacts, 
they in fact are solid state and contain 
no 
moving parts. 


The 
output 
configuration 
is utilized 
to turn 
the 
heater elements (the light bulbs) on and off. Figure 
17 provides 
us with a schematic 
of the output 
cir- 


cuitry. 
In this case, we will insert a solid state relay 


of type OAC5 
which will handle 
up to 140 volts 


RMS at 3 amps. 
In some cases, it might be desir- 


able to add certain 
components 
to the terminator 
panel when using it in the output 
mode. Two possi- 
ble circuit 
configurations 
are 
possible. 
The 
first 


and perhaps 
the most common 
will consist 
of in- 


stalling 
a MOY (metal 
oxide varistor) 
across 
the 


solid 
state 
relay 
contacts. 
This 
will be required 


when the load being driven is inductive 
in order to 
prevent 
the transients 
generated 
by the load from 
damaging 
the triac in the SSR (solid state 
relay). 


Since the SSRs utilize zero voltage 
switching 
and 


the load in our ovens is resistive rather 
than induc- 


tive, our application 
will not necessitate 
the instal- 
lation of this device. The second possibility 
for ad- 
ditional 
circuitry 
also 
involves 
driving 
inductive 
loads. 
When the load is highly inductive, 
a possi- 
bility exists that reliable operation 
of the SSR may 
not occur because of incorrect 
values for the dv/dt 


(a complete 
description 
of 
this 
phenomenon 
is 
available 
in various publications 
available 
from the 
manufacturers 
of 
the 
solid 
state 
relay 
devices). 
Provision 
has been made for installation 
of an ex- 
ternal 
snubber 
network 
should 
this be required. 
Again, our oven control system will not require this 
type of circuitry. 
Figure 
IS is provided 
for refer- 
ence should 
the reader desire to see the location 
of 
the additional 
components 
on the panel. 
It should 
be noted 
that 
the component 
placement 
does not 


allow the installation 
of the MOV and the snubber 


simultaneously. 


mm 


SOLID 
STATE 
RelAY 


We can now get back to the task of assigning 
ad- 
dresses to the various digital channels. 
The iCS 930 
panel has three connector 
options 
for connecting 
it 


to the computel's 
I/O 
ports. 
The standard 
con- 


figuration 
utilizes connector 
J2 to attach 
the rib- 
bon cable assembly. 
When this is done, 
the com- 
puter ports A and B will correspond 
to the 16 chan- 
nels on the terminator 
panel (Figure 
19). If we look 


at the termination 
panel, we will see that there is a 


provision 
for the user installation 
of two additional 
ribbon 
connector 
sockets 
onto 
the board. 
These 


are used in order to utilize the computer 
port C. If 
connector 
J3 is installed and utilized instead of 12, 


the channel assignments 
will be as shown in Figure 


20. In a similar 
manner, 
connector 
J I can be in- 


stalled and utilized to provide connections 
between 
the computer 
port C and the other eight SSR posi- 
tions. If we choose the 16 lines required 
for driving 


the indicator 
lamps 
from the iCS 920 panel to be 
ports 
A and B, then it seems reasonable 
tO,assign 


the eight remaining 
lines required 
on the iCS 930 to 
port C. A feature of utilizing standard 
ribbon cable 
assemblies 
is the ability 
to easily add ribbon 
plug 
connectors 
to 
the 
cable. 
This 
will result 
in an 


assembly 
transferring 
ports A, Band 
C to the iCS 
920 panel (however, 
port C is not used) and which 


continues 
the port C signals to the iCS 930 panel. 


Individual 
channel 
assignments 
can now be made, 
grouping 
the inputs and outputs 
together 
in groups 
of four (this is done because 
of a requirement 
of 
the single board computers 
to share terminator 
and 


driver component 
packages in groups of four). Fig- 


ure 21 provides 
a drawing 
showing 
the channel 
assignments 
and 
the 
physical 
wiring 
locations 
which will be used to connect 
the oven heaters and 
switches. 
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Final Channel Assignments 


The only task remaining 
before we have completed 


OUI 
task of assigning channel numbers 
and physical 


wire and 
component 
locations 
is to assign 
these 
channels 
on the iCS 920 digital termination 
panel. 


Since we have already 
determined 
that we will uti- 
lize ports A and B, this becomes 
a simple matter, 
requiring 
only 
an arbitrary 
assignment 
of 
lamp 


locations 
using 
these 
port 
bits. 
The 
assignments 
made 
for one oven can be seen in Figure 22. The 
entire 
ladder 
diagram 
of the system 
can now be 
completed 
along with port assignments 
for all sig- 
nals used. The completed 
diagram 
can be found in 


Appendix 
B. Note how the port assignments 
have 
been shown to the side of the ladder element repre- 
senting 
that interface 
device. 


The 
method 
used 
to 
define 
a port 
assignments 
needs to be clarified 
since it may not be apparent 


why a channel 
of port A was given the address 
of 
E80. To begin, we have already indicated 
that each 


port 
consisted 
of eight channels 
or bits. 
We will 


number 
these bits from 0 to 7. Since it is possible to 


have many input/output 
devices connected 
to the 
computer, 
the possibility 
exists of having multiple 
devices 
which 
incorporate 
internally 
ports 
A, B, 
and C. The computer 
has been designed to support 


up to 256 of these ports so we have numbered 
them 


using the hexidecimal 
numbering 
system. The pos- 


sible port numbers can then range from 00 to FF. It 
will be found that a common 
characteristic 
of most 
single board 
computers 
is the use of assigning 
the 
port addresses 
of E8, E9, and EA to the on-board 


8255 parallel 
peripheral 
interface. 
Therefore, 
the 


first channel 
of port A would be defined 
as having 
an address 
of E80; the second 
channel 
of port 
B 


would be E91, and so forth. 


III. SELECTING 
THE COMPUTER 
BOARDS 


To this point we have delayed 
the selection 
of the 


boards. which will be required 
to provide 
the com- 
puterized 
control 
system. 
The Intel OEM 
Micro- 
computer 
Systems 
Configuration 
Guide 
has been 


designed 
to simplify 
the task of selecting 
the re- 


quired 
system. 
Our first task is to enter all known 


information 
describing 
our desired system into the 


project 
configuration 
worksheets. 
These 
work- 


sheets can then be used to actually 
select a board 
configuration 
which meets our particular 
require- 


ments. The effort 
required 
to accomplish 
the entry 


of data is reduced to a minimum 
through 
the use of 


predefined 
digital and analog 
configuration 
work- 
sheets. 
Our 
requirement 
of having 
a total 
of 24 


parallel 
data lines, consisting 
of a mix of high and 


low 
level 
interfaces, 
can 
be met 
by 
the 
24-bit 
AC/OC 
combination. 
Our 
assignments 
of 
re- 


quirements 
for the terminator 
panels can be made 
and is shown 
in Figure 23. It can clearly 
be seen 


from 
the worksheets, 
that 
our required 
interface 
with the computer 
digital data will consist 
of one 
24-bit 
wide connector 
(had 
we not 
used 
port 
C 
assignments, 
the 
use 
of 
16-bit 
wide 
connectors 
would have sufficed). 
This means that our selected 
single 
board 
computer 
or 
I/O 
expansion 
board 


must provide at least one edge connector 
having 24 


I/O 
bits on it. 
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DIGITAL CONFIGURATION 
WORKSHEET 


PROJECT 
.. 
. 
_ 


This 
worksheet 
will 
provide 
the 
reqUired 
digital 
Interface 
conflgurallon 


data 
which 
IS reqUired 
to complete 
the 
ProJect 
Configuration 
Worksheet 


Enter Number of Channels 


Enter 
# of Discrete 
AC Outputs 
(115-230 
VAC) 


Enter 
# of Discrete 
AC 
Inputs 
(115-230 
VAC) 
. 


Enter 
# of Discrete 
DC Outputs 
(Current> 
300 MA) . 


Enter 
# of Discrete 
DC Outputs 
(Current 
< 300 MA) 
Enter 
# of Discrete 
DC Inputs 


Li 
(A) 
_4 
(B) 
_~ 
(C) 


Ua 
(D) 
o 
(E) 


Compute the Number of iCS 920'· and iCS 930'· Termination Panels 


First 
compute 
the 
number 
of Parallel 
I/O 
ports 
18-blts each 
port) 
required 
on your 
ISBC" 
board. 
Round 
all computations 
up to the nearest 
whole 
Integer 
unless 
Instructed 
otherwise' 


Compute 
# of ICS 930 Interface 
Output 
Ports 
(lA+C).8) 


Compute 
# of iCS 930 Interface 
Input 
Ports 
IB/8) 
. 
. 
. 
Compute 
# of iCS 930 Termination 
Panels 
(IF+G)/2) 
Compute 
# of ICS 920 Interface 
Output 
Ports 
(0.8) 
. 


Compute 
# of ICS 920 Interface 
Input 
Ports 
(E-8). 


Compute 
# of ICS 920 Termination 
Panels 
(lJ+K)/3). 


I 
IF) 


--.l 
IG) 


I 
(H) 
-2. 
(J) 


. .. 
~ 
(K) 


L 
(L) 


Optimization of Digital I/O Port Usage for Minimum I/O Configuration 


Compute 
# of ICS 930 Output 
"Overflow 
Channels" 
DO NOT 
ROUND 
OFF) 


(A+C)/8 
QUOTIENT. 
(Overflow 
Channels) 
REMAINDER 
Compute 
# of ICS 930 Input 
Overf'Jw 
Channels 
(DO 
NOT 
ROUND 
OFF) 


(B/8). 
. ... QUOTIENT. 


REMAINDER 
Compute 
# of iCS 920 Output 
Overflow 
Channels 
(DO NOT 
ROUND 
OFF) 


(0/8) 
QUOTIENT 
REMAINDER 
Compute 
# of ,CS 920 Input 
Overflow 
Channels 
(DO 
NOT 
ROUND 
OFF) 


(E/8). 
QUOTIENT. 
REMAINDER 
Compute 
8-Blt 
Input 
Ports 
ReqUired 
(P +V) . 


Compute 
8-Blt 
Output 
Ports 
Required 
(M +S) . 


Compute 
4-B,t 
Output 
Ports 
Required 
(IN +T). 4) (ROUND 
UP) 


Compute 
4-B,t 
Input 
Ports 
ReqUired 
«R +W)/4) 
(ROUND 
UP) 
Compute 
8-Bit 
Port 
C Requirements 
(IZ + AA)/2) 
(ROUND 
UP) 
Total 
I/O 
Parallel 
Ports 
Required 
(X +Y + BB) . 


Total 
# of 24 Channel 
Parallel 
I/O 
,SBC 
Board 
Edge 
Connectors 


(CC/3) 
(ROUND 
UP TO 
INTEGER) 
. 


Compute Power Requirements for the Termination Boards 
(DO NOT ROUND OFF) 


Compute 
+5V 
for 
,CS 920 Board 
Outputs 
1061' 
D) 


Compute 
+5V 
for 
ICS 920 Board 
Inputs 
1023' 
E) 


Compute 
+5V 
for 
ICS 930 Board 
Outputs 
I( 020' 
(A+ C)) 
Compute 
+5V 
lor 
,CS 930 Board 
Inpuls 
(012' 
B) 
Compute 
ICS 920 Power 
Requirements 
(EE 
+ FF). 
Compute 
ICS 930 Power 
ReqUirements 
IGG + HH) 


0 
(M) 
--.!l 
(N) 


0 
(P) 
..3 
(R) 


~ 
(S) 


0 
(T) 


i) 
IV) 
-0 
IW) 


D 
(X) 
2.- 
(V) 


L 
IZ) 
j 
IAA) 
I 
'(BBI 
~ 
(CC) 


--l 
(00) 


.. ..9& 
(EE) 


--0. (FF) 


.... 
~(GG) 


... 
~(HH) 


........... 
~(JJ) 


.. ... 
~(KK) 


The required power requirements of the termina- 
tion panels can be calculated using the data pro- 
vided in the digital configuration worksheet. The 
information 
regarding the necessary connectors 
and 
the 
power 
requirements 
should 
then 
be 
transferred to the project configuration worksheet 
(Figure 24). 


A similar technique is used to configure the analog 
signals using the standard analog configuration 
worksheet as shown in Figure 25. It can be seen 
that our application will require a single cable con- 
nection to a differential input edge connector of an 
analog input board. The power requirements can 
be calculated from the current requirements to 
drive the thermistors and the sensing resistors. The 
data is entered into the appropriate columns of the 
configuration tables and then transferred to the 
project configuration worksheet. 
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The only remaining physical element of our control 
system which we have not defined is the CRT ter- 
minal which will be used for setpoint entry and 
modification. Communications with a terminal re- 
quires that we provide a serial RS232C port in our 
control system. This port requirement is entered 


onto the worksheet and the system requirements 
are totaled as shown in Figure 26. 
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We must now choose the Intel iSBC boards which 
will provide a solution to our system requirements. 
This is done by referencing the summary of key 
iSBC configuration 
parameters 
to find boards 
which provide the necessary characteristics. Our 
first task is to choose a single board computer 
which meets as many of our needs as is practical, 
while providing performance characteristics ade- 
quate to our needs. 
Our first requirement for having support for a 
single RS232C serial communications channel can 
be seen to be met by a variety of possible boards. 
Among the possible boards meeting this require- 
ment are: 
iSBC 86/12™ 
iSBC 80120™ 
iSBC 80/30™ 
We must look further before a final choice can be 
made. Again, it can be seen that all candidates also 
meet the requirement of providing a minimum of 
one 24-bit wide digital I/O connector. Our decision 
must be based upon parameters which are not 
necessarily related to the input or output capabili- 
ties. Even though we have not yet developed our 
software package for our control system, we can 
safely make some assumptions regarding the com- 
pleted software package and thus define additional 
requirements which will enable us to select our 
desired computer board. The software task will be 
considerably simplified if we write our programs in 
a high levellanguage and if we use available drivers 
for our input and output where they are available. 
As we will see, the utilization 
of PL/M 
and 
RMX/80™ real-time executive and drivers will 
make this programming task much less demanding 
of our time. The trade-off is that these software 
tools take larger amounts of memory than if we 
were to write our entire application program in 
assembly language. Let us make an initial estimate 
that our system will require about 8K of EPROM 
and in the neighborhood of 2K of RAM. 


iSBC 80/IOA™ 
iSBC 80120-4™ 


Entering 
this data on the configuration 
worksheet 
(Figure 
27) enables 
us to narrow 
our 
choice 
by 
eliminating 
the iSBC 80/IOA since it does not have 
sufficient 
RAM on board. 


Since our application 
is not likely to require exten- 
sive math handling 
capabilities 
or high speed capa- 
bilities, 
we probably 
do not need the power found 
in the iSBC 86/12; 
so we will remove this product 
from consideration. 


We are now faced 
with selecting 
either 
the iSBC 
80120 board 
or the 80/30 board 
for our processor. 


Each has certain advantages 
and disadvantages 
for 
use in our application. 
Let's 
compare 
these 
two 
boards, 
considering 
first the iSBC 80120, then the 
iSBC 80/30. 


iSBC 80120 board 
advantages 
- 
Slightly lower 
cost, greater 
number 
of I/O 
lines available. 


iSBC 80/30 board 
advantages 
- 
Faster 
proces- 
sor, 
dual 
ported 
memory, 
able to utilize 
UPI 
modules. 


If the system were to operate 
in a stand-alone 
en- 
vironment 
and we could be certain that significant 
expansion 
would 
not take place, 
we would 
prob- 
ably choose the iSBC 80120 computer 
for our ap- 
plication. 
If we consider 
that 
the 
system 
might 
become 
a part 
of a much larger system by future 
expansions 
and 
additions, 
we should 
remember 
that the use of the UPI modules 
on the iSBC 80/30 
computer 
provides 
considerable 
power 
through 
multiprocessing 
capabilities. 
The 
dual 
ported 
memory 
can also provide 
us with the ability to use 
more 
sophisticated 
inter-board 
communication 
protocol 
should the need arise. For the purposes 
of 
this application 
note, we will assume the system is 
being designed 
for expansion 
and we will select the 
iSBC 80/30 computer. 


A good design practice 
is to provide 
an extra mar- 
gin of available 
memory 
in the hardware 
design. 
Our anticipated 
RAM 
memory 
will use about 
2K 
bytes. The computer 
will provide 
us with 4K bytes 
so we have a considerable 
margin. 
This is not true 
when we look at the amount 
of EPROM 
available 
on· the board. 
Our 8K requirement 
is identical 
to 


the 
amount 
of memory 
available 
to. us on 
the 
board. 
We should consider 
the use of an expansion 
EPROM 
board 
or the prospect 
of having to spend 
a considerable 
amount 
of time reworking 
our pro- 
gram to get it to fit if we find that we have exceeded 
our estimates. 
We will select the option of adding a 
memory 
expansion 
board 
(it can be deleted 
if we 
find that 
our software 
requirements 
are less than 
estimated). 


The computer 
selection and the memory expansion 
board data can now be entered onto the configura- 
tion worksheet 
as shown 
in Figure 
28. If needed, 
the addition 
of the memory 
expansion 
board 
will 
allow our EPROM 
requirements 
to grow up to 16K 
bytes. 


The only requirement 
which we have not met is to 
assign a board 
to handle the analog input needs of 
our temperature 
sensing circuit. The analog voltage 
can be calculated 
and will be found 
to lie in the 
neighborhood 
of 4.6 volts at room 
temperature. 
This 
value 
will 
increase 
toward 
5 volts 
as the 
temperature 
of the oven increases. 
Since we have 
no requirement 
for any analog output 
capabilities, 
we will choose the Intel@ iSBC 711 ™ 
Analog 
Input 
Board to sense the voltage level. This board 
can be 
configured 
to handle 
a 5-volt full scale input 
and 
will provide 
a resolution 
of 12 bits. (If an oven re- 
quiring 
a wide range 
of temperatures 
and greater 
resolution 
were required, 
we would have to recon- 
figure 
our temperature 
sensor 
to provide 
a wider 
voltage 
spread 
over 
operating 
temperatures. 
For 
purposes 
of simplicity 
and clarity 
we will assume 
that our temperature 
resolution 
is adequate.) 


The 
configuration 
worksheet 
can 
be filled in to 
reflect the selection of the analog converter 
and the 
total 
power 
requirements 
for 
the system 
can 
be 
computed 
as has been done in Figure 29. We now 
need to select a chassis and power supply in order 
to complete 
the application 
hardware 
design phase. 


The Industrial 
Chassis 


Before the boards can be operated 
together 
to form 
a controi 
system, a means of allowing communica- 
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tion between 
the boards 
and of distributing 
power 


among 
the boards 
must 
be found. 
This 
require- 


ment is met by specifying 
a chassis into which the 


boards 
will be mounted. 
The Intel"" iCS SO'" In- 


dustrial 
Chassis provides an environment 
for oper- 


ating 
the boards 
which is specifically 
designed 
to 


operate 
in an industrial 
area. 


The chassis has been designed 
to facilitate 
mount- 
ing into either a standard 
19-inch RETMA 
cabinet 


or it may be rear-panel 
mounted 
into an enclosure 


such as may be found in applications 
requiring 
the 
use of a NEMA electrical enclosure. 
The card chas- 


sis has been mounted 
in such a manner 
as to hold 


the single board computers 
and expansion 
modules 
vertically, 
facilitating 
maximum 
cooling 
of 
the 
boards. 
Fans are provided 
to aid the normal 
con- 


vection 
cooling 
process. 
Card 
racks 
may 
be in- 


stalled 
into the iCS SO chassis to expand 
the card 


support 
capability 
to a maximum 
of 12 card slots in 


groups 
of four. 
Either an iSBC 635 or 640 power 


supply 
can be mounted 
into the industrial 
chassis 


to provide 
power 
up to 4 or 12 boards 
capability, 
respectively. 


Our application 
design requires the installation 
of a 


three board 
solution, 
so we will choose the iCS SO 


chassis with one iSBC 635T\1 power supply. 
We will 
choose 
to mount 
our control 
system in a standard 
NEMA 
12 enclosure 
to protect 
the unit from 
the 
industrial 
environment. 
We should refer to the iCS 
80 Industrial 
System 
Site Planning 
and Installation 
Guide 
(manual 
order 
number 
9S0079S) for com- 
plete 
details 
for selecting 
appropriate 
enclosures 


and installation 
instructions. 


The + 5 volt power needed to support 
the various 


termination 
panels and to supply a reference 
volt- 
age for the thermistors 
is available 
from a barrier 
strip 
located 
on 
the 
lower 
front 
of the 
iCS 
SO 
chassis 
(Figure 
30). Our 
wiring can be routed 
to 
this barrier 
strip for those circuits 
requiring 
either 
5-volt 
DC or the system 
logic common. 
A fuse 


holder 
is provided 
and a fuse should 
be installed 


for system protection. 
We will install a 2-amp fuse 


into the holder 
(our maximum 
power requirement 
for external 
circuitry 
should 
be 1.22 amps accord- 
ing to Figure 26). 


The 
remaining 
terms 
required 
in our ladder 
dia- 


gram 
(Appendix 
B) consist 
of 
a 
high 
voltage 
neutral 
and 
a source 
of 
switched 
high 
voltage 
power for the heater lamps. Both of these terms are 
available 
from 
the iCS 80 industrial 
chassis. 
It is 
desirable 
to utilize 
the same switched 
power 
for 


both the computer 
system and our external signals, 


so that 
we can 
provide 
protection 
to operators 
when one portion 
of the system is shut down. 
A 


common 
source will insure that all portions 
of the 


system are inactivated 
if repair is being done. 
The 
iCS 80 chassis incorporates 
a heavy duty industrial 


key-lock 
switch 
for its power 
switching. 
The out- 


puts of this switch are available 
to the user at a ter- 


minal barrier 
strip located 
on a fold-out 
panel on 


the rear of the chassis assembly (refer to Figure 31). 
We can see that our neutral 
wire should 
be con- 


nected to terminal 
5 (filtered AC low) and the wire 


for the AC high, wire #10 on the ladder 
diagram, 
should 
be connected 
to terminal 
9. This will pro- 


vide us with a switched, 
fused, and filtered 
power 


source 
for our external 
wiring. 


As we will be installing 
the chassis into a NEMA 


enclosure, 
we will not want to use a standard 
power 
cord 
since this would 
involve 
the additional 
ex- 


pense of installing 
a duplex 
outlet 
in the cabinet. 


The power wiring can be installed 
directly onto the 


power barrier 
strip by placing 
the AC hot wire on 


barrier 
number 
I, the neutral 
wire onto 
barrier 


number 
4, and the ground 
onto barrier 
number 
3. 


The 
hardware 
implementation 
of the system 
can 


now be considered 
to be complete. 
Before the sys- 


tem can function 
as a control 
for the oven temper- 
atures, 
we must define 
the relationships 
between 


the various 
pieces of the oven system and we must 


also define the operator 
interface 
with the CRT ter- 


minal. 
Thus, 
we begin the software 
phase 
of our 


design. 


IV. DETERMINA nON 
OF SOFTWARE 


APPROACH 


The task of providing 
the relationships 
between the 
various 
system components 
falls into the category 


of writing the software. 
Before we actually begin to 


develop this software, 
we will define certain guide- 


lines which can be used to organize 
and simplify 


the task. 


Let 
us consider 
the 
general 
environment 
under 


which our programs 
will operate. 
We find that we 


have essentially 
two choices in this area. 
First, we 
can consider 
the entire process as a sequential 
set of 


predefined 
operations 
in which we must perform 
each 
operation 
before 
moving 
to the next 
until 


finally we complete 
the sequence 
and begin again. 


(This is analogous 
to using a single stepper 
switch 


to design our control system.) Since each oven is in- 
dependent 
of the others, 
we can not afford 
to use 
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this approach 
since we could get tied up waiting for 


something 
to 
happen 
in a particular 
oven 
and 


would have to ignore the other ovens. The designer 
familiar 
with relay design will probably 
be think- 
ing, at this point, 
that 
we should 
use a separate 


sequential 
operation 
for each oven or device to be 


controlled. 
Indeed, 
this is exactly what we can do 


with our software 
by using what is known as a real- 
time 
executive. 
This 
tool 
will allocate 
the com- 
puter's 
resources 
in such a manner 
as to provide us 


with the capability 
of having independent 
software 
programs 
or tasks operating 
at what appears 
to be 


the same time. We will make our first assumption 
that our software 
will be written 
using such a tool 


and 
we will specify 
that 
we will operate 
under 
Intel's 
RMX/80 
Real-Time 
Multi-Tasking 
Execu- 
tive. We will discuss 
more detail 
of this software 
tool as we develop 
our programs. 


Next, we must consider 
the language 
which we will 
use to actually 
define 
our required 
operation. 
We 
have many alternatives 
from which to choose. 
Let 
us look at several of the alternatives 
in some detail. 


Assembler 


Assembler 
language is probably 
the most basic tool 


with which we can program 
a computer. 
It is con- 


sidered 
to be the most efficient 
user of program 
memory 
and 
processor 
time. 
These 
features 
are 
made 
possible 
because 
each assembler 
instruction 
line 
is converted 
directly 
into 
a corresponding 


machine 
instruction. 
From a programming 
stand- 
point, 
assembler 
language 
is the most difficult 
to 
use since any task must be defined 
by subdividing 


that 
task 
into 
a multitude 
of smaller 
operations 


compatible 
with 
the available 
instructions 
of the 


computer. 
To use this language, 
we must be famil- 
iar with 
the architecture 
of each 
computer 
with 


which we desire to operate. 
The use of the language 
is somewhat 
simplified 
through 
the use of an Intel 


supplied 
assembler 
which 
converts 
the assembler 


code 
into 
machine 
instructions 
and 
provides 
list- 
ings of the operations 
which have been entered. 
A 


complete 
description 
of the 
Intel 
8080/8085 
As- 


sembler 
Language 
is available 
in the 808018085 


Assembly 
Language 
Programming 
Manual 
(man- 
ual order number 
9800301 B). 


The 
user should 
consider 
this programming 
tool 


when 
his 
application 
requires 
the 
minimum 


amount 
of memory 
(such as might be required 
for 


very large volume designs where memory 
cost is a 


factor) 
or where a highly time dependent 
routine 


must be defined. 
Our oven application 
does not fall 
into either 
of these categories, 
so we will choose 


not to use this language 
in our instance. 


PLiM 


Intel's 
PL/M 
language 
offers 
an efficient, 
struc- 
tured, 
high level systems 
programming 
language. 
Before proceeding, 
let us be clear on the benefits of 


using a high level language. 
First, the use of high 
level languages 
results in reduced development 
time 
and cost. 
High level languages 
provide 
the ability 
to program 
in a natural 
algorithmic 
language. 
In 
addition, 
they eliminate 
the need to manage 
regis- 
ter usage or to allocate memory. 
Second, 
high level 
languages 
provide 
improved 
product 
reliability 


because 
programs 
tend to be written 
in structured 
formats 
and 
result 
in a minimum 
of extraneous 


branches 
which 
might 
cause 
testing 
problems. 


Finally, their use produces 
programs 
which are bet- 
ter documented 
and are easier to maintain. 


On the other hand, high level languages 
do not op- 
timize the code segments 
as well as can be done by 
. an experienced 
assembly language programmer. 
As 


a result, 
most 
compilers 
(routines 
which 
convert 
the high level languages 
into 
machine 
executable 


code) use more program 
storage 
than those written 
by the assembly 
language 
programmer. 
Different 
languages 
and compilers 
require different 
amounts 


of memory 
for the same task. 


PL/M-80 
is probably 
one of the most efficient 
high 
level languages 
for use on microcomputers. 
It has 


been determined 
that PL/M-80 
users can expect to 
use between 
I. I to slightly 
more 
than 
2 times as 


much program 
memory 
as would 
be used for the 
same task written 
in assembly 
language. 
For this 


reason, 
we must place the use of this language 
high 
upon our list of possible languages 
in this applica- 
tion. 


A glance 
at the PL/M-80 
Programming 
Manual 
(manual 
order number 
98-268B) indicates 
that the 
language 
is highly 
structured 
and 
seems 
to lend 
itself very well to handle logical type operations. 
It 
seems 
to have the greatest 
weakness 
in its math 
handling 
capabilities 
in that 
it does 
not 
support 
negative 
numbers 
or fractions. 
It is reasonable 
to 


assume 
that 
the oven application 
can be handled 
entirely 
with 
positive 
integer 
numbers 
so 
this 


limitation 
will not unduly 
hamper 
our use of this 


language. 
We will keep these features in mind when 
making 
a final decision. 


FORTRAN 


Intel's 
FORTRAN-SO 
provides 
the full subset 
of 
ANSI 
FORTRAN 
77. In many cases FORTRAN- 


SO has features 
that 
exceed the specifications 
for 
both the subset and the full versions of FORTRAN 
77. Most of the power 
of this language 
lies in its 
ability 
to easily handle 
complex 
mathematical 
ex- 


pressions. 
Obviously, 
it does not have any limita- 


tions regarding 
fractions 
or sign of the nurpbers 
in- 


volved. 
It should 
be used when the application 
re- 
quires the use of mathematical 
computations. 
The 
power 
of the language, 
however, 
means 
that 
the 
use of the language 
will take a heavy toll of mem- 


ory allocation. 
A complete 
description 
of the FOR- 
TRAN version supported 
by Intel and its use on the 
iSBC computers 
can be found 
in the FORTRAN- 


80 Programming 
Manual (order number 9S004S1 A) 


and in the ISIS-II 
FORTRAN-80 
Compiler 
Opera- 


tor's Manual 
(order number 
9S004S0). 


It is unlikely 
that 
the magnitude 
of mathematical 


routines 
required 
to control 
the temperature 
of our 
ovens will be complex enough 
to justify 
the use of 
FORTRAN. 
Keep in mind that, if such a situation 
were encountered, 
it is feasible to use a combina- 
tion of programming 
languages 
to create our final 


module. 


BASIC 


Certaintly 
the most well known high level program- 


ming language 
today 
is BASIC. 
It offers 
a quick 


way of applying 
the computational 
capabilities 
of 


the computer 
to a wide range of applications. 
The 
Intel RMX/SO 
BASIC-SO is an interpreter 
designed 


to operate 
with Intel's 
single board computers 
and 


contains 
extended 
disk handling 
capabilities. 
As an 


interpreter, 
it differs 
from 
other 
high 
level lan- 
guages in that it results in a relatively slower oper- 
ating solution 
to an application. 
It is also not possi- 


ble to use BASIC to generate 
multiple independent 


tasks which can compete 
for c'omputer 
resources. 


For these reasons, 
we cannot 
consider 
the use of 
BASIC 
for a solution 
to our application. 


Final Selection 
of Language 


From 
the above discussion, 
it seems clear that our 


choice for the application 
being demonstrated 
is to 
use PL/M-SO 
as our programming 
language. 


With this in mind, we can begin the task of actually 
generating 
the code which will complte our applica- 
tion and provide 
an operating 
control 
system. 


V. DEFINING 
SOFTWARE 
TASKS 


The software 
implementation 
can begin as soon as 
we have broken 
our control 
functions 
into inde- 


pendent 
"tasks". 
We can then 
handle 
each 
task 
separately 
as though 
it were the only thing which 


had to be done by the control 
system. 
In the event 


that we find that one of our tasks must communi- 
cate with or be interlocked 
with another, 
we will 


handle 
this need through 
the use of "exchanges". 


The "exchange" 
can be thought 
of as a mailbox in- 


to which messages are deposited 
and picked up by 


the various tasks. These messages convey the neces- 
sary information 
between 
the otherwise 
independ- 
ent programs. 
When all tasks have been coded, 
we 
will combine 
them using the facilities of RMX/SO. 


Our 
oven 
application 
can 
be broken 
down 
into 


three functional 
areas or tasks. These are: 


I. The Control 
Task which will be used to actually 
sense the oven temperature 
and to provide 
the 


required 
responses 
to the heaters 
and the indi- 
cator 
lamps. 


2. The CRT Update Task will be used to provide a 
"snapshot" 
of the system operations 
to a per- 
son viewing the CRT terminal. 


3. The Parameter 
Update 
Task will be used to ex- 
amine and update 
the oven setpoints 
and toler- 
ances. 


The choice of these three tasks has been essentially 
arbitrary 
in nature. 
Certainly, 
other 
choices 
and 
groupings 
of 
functions 
could 
easily 
have 
been 


made. 
We will use these choices 
for our example 


and 
will proceed 
with 
our 
development 
accord- 


ingly. 


We have two other supporting 
tasks which must be 


included in our system. Fortunately, 
these tasks are 


predefined 
and fully supported 
within 
RMX/SO's 


libraries; 
thus we need not write these functions. 
The two supporting 
tasks are: 


4. A Terminal 
Handler 
Task to support 
the actual 


interface 
to the CRT terminal. 
It provides 
echo 
of input 
characters 
and 
signals 
when 
data 
is 


ready to be read. It will output 
messages to the 


terminal 
and 
signal 
when 
all 
characters 
re- 


quested 
have been sent. 


5. An Analog 
I/O Driver Task to request and han- 


dle 
the 
handshaking 
which 
is 
required 
to 
communicate 
with the analog 
input 
board. 
It 
will signal us when data has bee,n input 
and is 
available 
for use by our user written 
tasks. 


We can proceed 
with the implementation 
of each 


of our three tasks which we have defined. 
The first 


step with each will be to develop a flowchart 
which 


shows 
the required 
operations 
to implement 
that 


task. 
This flowchart 
will show any intertask 
com- 


munications 
or exchanges 
that 
may 
be required 


with other tasks. The flowchart 
can then be coded 


using the facilities 
provided 
by our programming 
language. 


Oven Control Task 


The sequence 
of operations 
required 
to perform 


the control 
task can be defined 
using the flowchart 


shown 
in Figure 
32. Let us examine 
the required 


steps in more detail. 


An arbitrary 
decision 
has been made to only sam- 
ple and control 
the ovens once each second. 
This 
will allow some time for the system to respond once 
a heater output 
has been set. The first step in our 
control 
task is to wait for one second 
to elapse. 


Our next subtask 
should be to read the status of the 
various 
oven 
control 
switches 
on the operator's 
control 
panel. 
This 
item could 
wait until a later 
time, 
but there 
is no harm 
in handling 
it at this 
time. 


Next, 
we see a block indicating 
the input of data 
regarding 
the current oven temperatures. 
This oven 


temperature 
data will certainly 
be used by the task 


handling 
the snapshot 
display 
on the CRT so we 
must give some consideration 
to the validity of the 
data. 
While we are in the process 
of getting 
the 
data 
and converting 
it to engineering 
units (next 


step), there will be periods during which the stored 
temperature 
data 
does not reflect 
the actual 
oven 


temperature. 
An example might be when we are ac- 


tually moving 
the 16 bits of the temperature 
since 
we can only move data 8 bits at a time. During this 
period, 
we would not want another 
task to use the 
data and since each task is going to operate 
inde- 


pendent 
of others, 
we must provide 
some type of 
lockout 
of the data while we are operating 
on the 
temperatures 
(an alternative 
would be to have each 


task get its own temperature 
from 
the AID 
con- 


verter and convert 
it to engineering 
units, 
but this 
would seem to waste memory 
and computer 
time). 
We can 
provide 
this lockout 
by creating 
an ex- 
change 
to communicate 
with 
other 
tasks. 
If we 
make a message available in this exchange when the 
data is valid and cause no messages to be available 
when the data is nonvalid, 
we can effectively 
lock 
out tasks from using the data when it is in the pro- 
cess of being updated. 
This is done 
by requiring 


those tasks to test for the presence of a message at 
the exchange 
before they get the temperature 
data. 


If no message is present, 
they must wait until one is 


placed 
into the exchange 
before 
proceeding. 
Just 
before we update the temperatures 
we will fetch the 


message from the exchange, 
leaving it empty while 
we work on the data. 
later we will again restore the 


message when the update 
is complete. 


The number 
obtained 
from 
the analog 
converter 
provides 
us with a value which is proportional 
to 
the temperature 
of the oven. 
Our 
next step is to 


convert 
this number 
into engineering 
units. Unfor- 
tunately, 
the 
voltage 
and 
temperature 
are 
not 


related 
in a linear fashion 
since the thermistor 
is a 


nonlinear 
device. 
We will have to develop 
a tech- 


nique to obtain a corrected 
value. For the purposes 
of this application 
note and in an attempt 
to keep 


the 
application 
as 
simple 
as 
possible, 
we have 


chosen 
to utilize a single table look-up 
to perform 


this conversion. 
Alternatives 
might 
have been 
to 


utilize FORTRAN 
routines 
to mathematically 
per- 


form the conversion 
or to have separate 
tables for 


each oven. Once the conversion 
has been made, we 


must return a message to the data lockout exchange 
to allow other tasks access to the data. 


Because we must deal with four ovens, 
the opera- 


tions related 
to each individual 
oven must be per- 


formed 
four 
times, 
once 
for each. 
This is easily 
handled 
as we will see, since PL/M 
is a block struc- 


tured language. 
Our flowchart 
need only remind us 
that the operations 
need be done four times. 


The next step has been defined as performing 
some 


digital filtering of the temperature 
by averaging 
the 


current 
temperature 
with the temperature 
of one 


second ago. This filtered value will be used to per- 
form subsequent 
computations 
and to make future 
decisions. 


We have defined 
earlier 
in our definition 
of the 
control 
algorithm 
that 
we would 
use a derivative 
control. 
We have chosen 
to project 
the tempera- 


ture ahead 
for a period 
of 10 and 30 seconds. 
We 
must 
calculate 
the 
rate 
of 
change 
and 
the. 


temperatures 
in 10 and 30 seconds so that this data 


will be available 
when needed. 


Now that the calculations 
have been made to deter- 


mine numeric values required 
for the decision mak- 


ing process, 
we must begin the process of determin- 


ing the status of each indicator 
and oven heater. 
A 


test will be made of the oven run switch and if it is 
found 
to be turned 
off, 
we will turn off all indi- 


cators 
and 
the oven 
heater 
associated 
with 
that 
oven. If the switch is found to be turned on, we will 
set the status 
of the "in 
tolerance", 
"caution", 
and "alarm" 
indicators 
according 
to our oven con- 


trol algorithm. 
The oven heater 
will be turned 
on 


or off according 
to the projected 
temperature 
in 30 


seconds. 


Rather 
than 
output 
the individual 
oven indicator 


and heater data four times (once for each oven), we 


will 
perform 
the 
computations 
associated 
with 


making 
the decisicn 
four 
times 
(this 
saves 
code 
since we can use the same program 
steps with only 


pointers 
being exchanged). 
At the end of this time, 
a single operation 
will output 
the data to all ovens 
and indicators 
at the same time. 
Outputting 
to a 
computer 
port will actually cause the device to turn 


on or off according 
to whether 
the output 
bit is a 


one or zero. 
, 


We will then return to the beginning 
of our task to 
wait until another 
second 
elapses before 
we again 


perform 
the indicated 
functions. 


Control Task Source Coding - 
The coding of our 


tasks is a straightforward 
procedure 
once we have 


prepared 
a flowchart. 
Since we are using PL/M-80 
and RMX/80, 
the coding sequence 
for a task will 


be as follows: 


I. Define any variables 
or structures 
which will be 


used in the module. 
This involves providing 
in- 


formation 
defining variables as being either an 8 


or 16-bit variable 
and declaring 
if that variable 


is to be a part of the task being coded or is to be 
found in some other task. If any array~ or struc- 
tures are to be used, they must also be defined. 
Finally, if any program 
locations 
are to be used, 


they must be declared. 


2. The task must be initialized. 
That is to say that 
any assumptions 
which will be made as to initial 


data values in subsequent 
instructions 
must be 


initially 
forced 
to this initial value. 


3. The 
actual 
task 
must 
be coded 
to match 
the 


operations 
called out in the flowchart. 


We will look at some examples 
of this coding pro- 


cess using the control 
task flowchart. 
The complete 


listing of this module and all modules 
actually used 


to provide 
the oven control 
system can be found in 


Appendix 
C. 


At first glance, 
it would seem that the listing is ex- 


tremely complex, 
but as we will see it is made up of 


straightforward 
pieces. 
The listing is made 
up of 


three parts as we have mentioned 
above when de- 


fining 
the steps required 
to generate 
a program. 


The first part (line numbers 
I through 
50) is used to 


define 
parameters, 
variables, 
and 
external 
ele- 


ments. 
The general 
types of elements 
making 
up 


this portion 
fall into typical 
categories. 
The first 


general 
category 
consists 
of 
DECLARE 
state- 


ments. 
E..~mples of typical lines will help explain 


their meanings 
(when actually 
developing 
the pro- 
gram, 
this first section 
was created 
piecemeal 
by 


making an entry \\ hen it \\ as found that a need for 
that term existed as the execution 
code in sections 


two and three wcre written). 


Examples 
of the "declare" 
statement 
are shown 


below. 
For example, 
on line II we find: 


II 
I 
Declare 
(n,k) 
byte: 


This means that the variables "ri" and "k" 
are be- 


ing defined 
as terms 
which represent 
numbers 
or 


data which is one byte or 8 bits wide. The" 
II" 
is 
the program 
line number, 
and 
the" 
I" 
indicates 
that we are in the first level of nesting. 


We can also see the use of the "literal" 
expressions 
such as used in line 4. The expression: 


4 
I 
DECLARE 
FALSE 
LITERALLY 
'OOH"; 


means that we are creating a new instruction 
called 


"false" 
and that its meaning 
is to be interpreted 
by 


the compiler 
as being 
equivalent 
to the value 
of 


zero. 


Rather 
than dwell on the declaration, 
let us move 


on to the coding process which was used to gener- 
ate the actual 
program. 
Keep in mind that the use 


of PLlM-80 
requires 
that 
all terms 
used 
be de- 


clared in the program 
module. 
Refer to the PLIM- 


80 Programming 
Manual 
(order number 9800268B) 


for a full description 
of the PLiM 
language. 


Program Initialization - 
The initialization 
portion 


of the program 
can be found on lines 51 through 
59 


of the control 
task program 
listing. This section is 
used to initialize data and to provide 
known entry 


conditions 
before 
we enter the repetitive 
program 
loop. This code is only executed when the system is 
reset or when the power is turned 
on. The control 
task requires 
two types of initializations; 
one to in- 


itialize the computer's 
output 
port and the other to 


set up the AID 
converter. 
The requirements 
for 


each can be found 
in the 
RMX/80 
User's 
Guide 


and the iSBC 80130 Single Board Computer 
Hard- 


ware Reference 
Manual 
(order number 
980061IA). 


Actual 
instruction 
examples 
are 
given 
in 
these 


manuals 
for the initialization 
operations. 


Program Body - 
The program 
which actually pro- 


vides the control 
operations 
can be found on lines 
60 through 
126 of the program 
listing for the con- 
trot task. 
It has been divided 
into sections 
which 


correspond 
directly 
to 
the 
flowchart 
that 
was 
prepared 
earlier. 
Most 
instructions 
in PL/M-80 
language 
follow closely the English structure 
which 


describes what is being done. The exceptions 
gener- 


ally follow 
definite 
predefined 
formats. 
The for- 


mat such as used on line 61 to wait for one second 
to elapse is an example of one such exception. 
Any 


time we desire to wait for a definite time period, we 
use an instruction 
of the form: 


MSG$PTR=RQWAIT 
(.DUMMY$EXCH, 
TIME 
DELAY); 


Whatever 
time delay we wish to use is expressed 
in 
increments 
of 50 msec time periods. 
Our example 


requires 
a time delay of one second so we will use 


the delay notation 
of 1.010.050 = 20 time units (this 
command 
is actually calling upon the RMX/80 
ex- 
ecutive to handle 
the delay). 


The oven enable switch data has been defined by us 
to be routed 
by the hardware 
to the computer 
port 
"EA" 
which converts 
to a decimal number, 
234. If 
we define an internal 
memory location 
for this data 
and 
call it BLOCKO, 
then 
we can 
get the oven 
switch data by using an input statement. 
Since the 


data sense is inverted through 
the hardware, 
we can 
provide meaningful 
internal 
data if the signal is re- 
inverted 
as it is loaded 
into memory. 
The instruc- 
tion on line 62 of the control 
task listing performs 


this task. 


We are now ready to get the analog data from the 
AID 
converter. 
Our flowchart 
shows that we must 


lock out the other tasks from access to the tempera- 
ture data during 
this time period, 
so we must first 
remove 
the enable 
message 
from 
the exchange 
in 


which it is stored. 
Messages are removed 
from an 
exchange 
by using an instruction 
of the form: 


STORAGE 
= RQWAIT-(EXCHANGE 
NAME,O) 


Lin'e 63 of the program 
listing means that we will 
get a message from our storage 
exchange 
which is 


called 
"Temp$lockout$exch" 
and 
store 
it in a 


memory 
storage 
area called" 
Lockout". 
Now, no 
other 
task can get a message 
from 
this exchange 
since it is empty, 
so it is permissible 
to operate 
on 
the temperature 
data. 
(Note how similar this com- 
mand is to the one used to wait for a delay. Indecd, 
this is the same 
request 
for 
RMX/80, 
but it re- 


quests a time delay of zero.) 


During the initialization, 
we built a message defin- 


ing the characteristics 
of the analog 
signals and of 


the analog 
conversion 
board 
which we are using. 


Remember 
that we have indicatcd 
that the task of 


getting this data from the board is provided 
to us by 


one of RMX/80's 
predefined 
drivers. 
All that 
is 


necessary at this time is to inform that driver of our 
desire to get data, then wait until it has done its job 
and the data 
is available 
for us. The actual 
com- 


munication 
between 
our applications 
task and the 
analog driver is done using the idea of an exchange 
similar 
to that we have used to lockout 
the data. 


A flowchart 
can now be prepared 
showing the steps 
required 
to implement 
the CRT update 
task. This 
flowchart 
is shown in Figure 34. The coding of the 


program 
to support 
this task can be found 
in Ap- 


pendix 
C. The development 
is identical 
with that 


which 
we described 
in the sections 
regarding 
the 
control 
task. 
Again, 
the software 
is divided 
into 
three parts, 
the declaration 
statements 
from lines I 


to 81, the initialization 
on lines 82 to 87, and the 
actual 
task code on lines 88 to 207. 


A technique 
to exit from 
the CRT 
update 
mode 
and to get into a mode which will allow modifica- 
tion of the parameters 
has been introduced 
into the 


program 
and 
the display 
format. 
This 
is in the 
form of a message on the botton 
of the screen re- 


questing 
the entry of an escape character 
to adjust 


setpoints. 
The software 
has been written 
in such a 


manner 
as to test for a character 
inut from the key- 


board 
and if one is found 
corresponding 
to that 
character, 
the update 
task will allow the parameter 


update 
task to take control 
of the terminal 
(lines 


190 to 204 of the listing). 


Parameter Update Task 


The parameter 
update 
task is used to actually allow 


the modification 
of the setpoints 
and the tolerances 
associated 
with each oven. A second use of the task 


is to provide 
a tool for establishing 
the zero offset 
associated 
with each analog channel so that an off- 
set into the temperature 
linearization 
table can be 
computed 
by the control 
task. 


Figure 35 shows the flowchart 
which describes 
the 
ste"ps required 
to perform 
these operations. 
When 


the task has been completed, 
we will return 
to the 
CRT update 
task. 


The program 
code for this task can be found in Ap- 


pendix C and again follows the formats 
which we 


have discussed 
earlier. 
No attempt 
will be made in 


this document 
to provide 
a narrative 
of the listing 


since it follows the flowchart 
in development. 


Support 
Programs 


Three subprograms 
(procedures) 
have been written 


which provide 
functions 
which are common 
to the 


three tasks. This has been done to minimize repeat- 
ing code segments 
thus saving as much memory 
as 


possible. 
These three subprograms 
support: 


1. Conversion 
of a decimal string from the termi- 


nal into a binary number. 
This program 
is called 


ASC$2$BINARY 
and can be found 
in Appen- 


dix C. 


2. Storage 
for 
common 
variables 
used 
by more 


than one task. These variables could easily have 
been included 
in other 
tasks but a purely arbi- . 


trary 
decision 
was made 
to include 
them 
in a 


separate 
module. 


3. Conversion 
of binary 
numbers 
into a decimal 


string suitable 
for output 
to the terminal. 
This 
program 
is called 
DEC$REP 
and 
is found 
in 


Appendix 
C. 


We now have completed 
the coding of the software 


to support 
our oven application. 
We must finish by 
combining 
all the 
software 
together 
to 
form 
a 


single loadable 
module. 


VI. FINAL IMPLEMENTATION 


When 
all code was linked and loaded 
to form an 


executable 
program 
module, 
it was found 
that the 
system required 
9,041 bytes of EPROM 
and 1,735 


bytes of RAM. 
These values fall within our hard- 
ware capabilities 
and will rquire 
that we program 


and in~ert nine EPROMs 
into the EPROM 
expan- 
sion card. 


The system can now be tested and installed 
to con- 


trol the ovens of our application. 
The actual system 
described 
in this application 
note 
has been con- 


structed 
and tested. 
It has been found 
to control 


the oven temperatures 
of four ovens and performs 


as we anticipated 
when we developed 
our control 


strategy 
earlier in this application 
note. 


VII. CONCLUSION 


We 
have 
shown 
how 
Intel's 
single 
board 
com- 
puters, 
industrial 
chassis, 
termination 
panels, 
and 


software 
can be configured 
to provide a solution 
to 


a typical control application. 
We have seen how the 


development 
of a solution 
to a control 
problem 
can 


proceed 
along 
a predetermined 
and 
logical 
path. 


Truly, 
the utilization 
of the microprocessors 
can 


lead 
to optimum 
and 
cost· effective 
solutions 
to 


control 
applications. 


We will send a message to the analog driver telling 
it what we want it to do, then we will wait until it 
sends a message back to one of our exchanges 
tell- 


ing us that 
it is done. 
The format 
for sending 
a 


message 
to an exchange 
always follows the form: 


CALL RQSEND (EXCI'IANGE NAME, MESSAGE NAME); 


Line 64 of the listing shows that we have requested 
the input of the analog data since we have sent our 
message, 
Convert, 
to the analog 
driver's 
exchange 
which 
is called 
RQAIEX. 
We will wait until 
the 
operation 
is complete 
by using 
the line of code 
shown on the listing line 65. This is the same opera- 
tion type that we used to get our message back pro- 
viding a lockout 
earlier. The program 
will wait un- 


til a message is available 
before continuing. 


The data 
must now be converted 
into engineering 
units. 
We earlier 
indicated 
that 
we would 
use a 


table 
lookup 
to perform 
the linearization, 
so we 
have included 
this table as a part of our program 
at 


line 50. The offset into the table corresponding 
to 
our temperature 
must 
be determined 
so that 
the 
correct 
value can be stored. 
Because we have four 


ovens, 
we will perform 
the operation 
four 
times 
with the data 
each time corresponding 
to the ap- 


propriate 
oven. 
These operations 
can be followed 


on lines 77 through 
81 of the listing. 


Lines 67 through 
76 are used to establish 
an offset 
to be applied 
to the analog temperature 
data when 


the system 
is running. 
This 
program 
is only de- 
signed 
to be used during 
the start-up 
operations 
and is activated 
when a message containing 
a cali- 


bration 
request 
and current 
temperature 
is sent to 
its exchange. 


The 
temperature 
lockout 
must 
be 
removed 
to 
enable other tasks to use this data. This is done on 
line 82 by sending 
the message 
back 
to the ex- 


change used for intertask 
lockout communications. 


The remainder 
of the program 
follows 
the flow- 


chart 
and the operations 
can be followed 
using a 
flowchart 
and the listing. Each element of the flow- 
chart corresponds 
to a block of code on the listing. 


CRT Update 
Task Development 


Earlier, 
we stated that the CRT update 
task would 


be used to allow the operator 
to view a "snapshot" 
of the four 
ovens. 
Let us turn 
our 
attention 
to 
developing 
the software 
which 
is required 
to ac- 


complish 
this. 
We can begin by defining 
the ele- 
ments 
which 
we feel should 
be displayed, 
then 


defining 
the format 
to actually 
be used with the 
CRT terminal. 


Obviously, 
we need to provide the current 
tempera- 


ture of each oven on our display screen. 
If we dis- 


play the actual temperature, 
it seems reasonable 
to 
assume 
that 
we should 
also show the setpoint 
so 


that a determination 
can be made as to how well 


the system 
is performing. 
The control 
algorithm 


has been defined to use an allowable 
range to deter- 


mine system outputs, 
so it would seen wise to also 
show this parameter. 
Finally, we should inform 
the 
viewer of the status of the oven so that he will real- 
ize that 
the reason 
an oven temperature 
is low is 


because 
the oven is off rather 
than 
an oven mal- 


function. 
Other items could be added if desired by 


the system designer, 
depending 
upon the total sys- 
tem 
requirements 
or 
the 
characteristics 
of 
the 


users. 


We can now prepare 
a drawing 
of the CRT display 


to generate 
a layout of our desired 
characters 
and 


to generate 
an aesthetic 
display 
for viewing during 
operation. 
This drawing can be found in Figure 33. 


Several 
techniques 
are available 
to output 
the re- 


quired displays to the terminal. 
A decision 
must be 


made as to the frequency 
of screen updates; 
will we 
constantly 
refresh 
the data or do it only at certain 


intervals 
of time? If the terminal 
has the ability to 


disable 
the cursor, 
it makes 
sense to update 
data 


continuously. 
If the cursor 
cannot 
be disabled, 
its 


movement 
tends to be distracting, 
so the updates 
should 
be kept to a minimum. 
The terminal 
used 


for 
the application 
note 
did 
not 
have 
a disable 


feature, 
so we will make the decision 
to only up- 


date the screen once each second. 


The 
decision 
to delay 
updates 
leads 
us to make 
another 
decision 
regariling 
the screen 
updates. 
If 
we only update 
a line which 
has data 
which 
has 
changed 
since the last update, 
the cursor 
move- 


ments will be kept at a minimum 
since it is unlikely 
that all parameters 
will ever change each second. 


APPENDIX 
A 
SELECTED 
DATA SHEETS 


• 
Gallium Arsenide Diode Infrared Source Optically Coupled 
to a Silicon N-P-N Darlington-Connected 
Phototransistor 


• 
High Direct-Current 
Tramfer 
Ratio _.. 300% Minimum at 10 mA 


• 
Base Lead Provided for Conventional Transistor Biasing 


• 
High-Voltage Electrical Isolation ... 
1500-Volt Rating 


• 
Plastic Dual-in-Line Package 


• 
Typical Applications 
Include Remote Terminal Isolation, 


SCR and Triac Triggers, Mechanical Relays, and 
Pulse Transformers 


The package 
consists of 
a gallium 
arsenide infrared·emitting 
diode 
and an n-p·n silicon 
darlington-connected 


phototransistor 
mounted on a 6-lead frame encapsulated within 
an electrically 
nonconductive plastic compound. The 


case will 
withstand 
soldering temperature with 
no deformation 
and device performance characteristics remain stable 


when operated in high humidity conditions. Unit weight is approximately 0.52 grams. 
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NOTES: 


a. 
Leads 
are 
within 
0.005 
radius 
of 
true 
position 


(TP) 
at 
the gauge plane with 
maximum 
material 


condition 
and 
unit 
installed. 
b. 
All 
dimensions 
are 
in 
inches 
unless 
otherwise 


noted. 


c. 
Pin 
1 
Identified 
bV 
index 
dot. 
d. 
Terminal 
connections: 


'. 
Anode 
} 
Infrared .• mittlng 


2. 
Cathode 
diode 


3. 
No 
internal 
connection 


4. 
Emitte, 
} 


5. 
Collector 


6. 
Base 
(For 
TIL 119. 
make 
Phototransistor 


no external 
connection) 


absolute maximum ratings at 25°C free-air temperature 
(unless otherwise noted) 


Input-to-Output 
Voltage 
Collector-Base Voltage (TI L113) 
. 
Collector-Emitter 
Voltage (SeeNote 1) 
Emitter-Collector 
Voltage 
Emitter-Base Voltage (TI L113) . 
Input·Diode ReverseVoltage 
Input· Diode Continuous Forward Current at lor below) 25°C Free·Air Temperature (SeeNote 2) 
Continuous Power Dissipation at (or below) 25°C Free·Air Temperature: 
Infrared-Emitting 
Diode 
(See Note 3) 


Phototransistor (SeeNote 4) 
Total 
(Infrared-Emitting 
Diode plus Phototransistor, 
See Note 5) 


Storage Temperature Range 
Lead Temperature 1/16 Inch from Casefor 10 Seconds 


±1.5 kV 


30 V 
30V 


7V 
7V 


3V 
100mA 


150mW 


l&OmW 
250 mW 


_55°C to 150°C 


260°C 


NOTES- 
1 
This 
value 
applies 
when 
the 
base 
emitter 
diode 
IS open 
cirCUited. 


2. 
Derate 
linearly 
to 
100:C 
free-air 
temperature 
8t the 
rate 
of 
1.33 
meA/C. 
3. 
Derate 
linearly 
to 
100 
C free·a,r 
temperature 
at 
the 
rate 
of 
2 mINI 
C. 


4. 
Derate 
linearly 
to 
lOOoe 
free 
aIr temperature 
at 
the 
rate 
of 2 mWfC 


5 
Derate 
linearly 
to 
100° C free·air 
temperature 
at the 
rate 
of 
3.33 
mWt' 
C 


TEXAS INSTRUMENTS 
INCORPORATED 


poaT 
OFFICE 
aox 
S012 
• 
QALLAS, 
TEXAS 
15222 


TYPES 
TIL113. TIL119 


OPTO-COUPLERS 


TEST CONDITIONS' 
TIL113 
TIL119 
PARAMETER 
UNIT 


MIN 
TYP 
MAX 
MIN 
TYP 
MAX 


Collector-Base 


J() 
VIBR)CBO 
IC=10"A, 
IE = 0, 
IF = 0 
V 
Breakdown 
Voltage 
I 


COllector-Emitter 
VIBR)CEO 
IC = 1 mA, 
IB = 0, 
IF = 0 
30 
30 
V 
Breakdown 
Voltage 


Emitter-Base 


VIBR)EBO 
IE = 10"A, 
IC = 0, 
IF = 0 
7 
V 
Breakdown 
Voltage 


Emitter-Collector 
V 
VIBR)ECO 
IE = 10"A, 
IF = 0 
7 


Breakdown 
Voltage 


On-State 
VCE = 1 V, 
'B - 0, 
'F -10mA 
30 
100 


IClon) 
mA 
Collector Current 
VCE - 2 V, 
IF 
10mA 
30 
160 


Off·S,ole 


100 
100 
nA 
ICloff) 
Collector 
Current 
VCE = 10 V, 
'B = 0, 
IF = 0 


Transistor 
Static 


hFE 
Forward 
Current 
VCE = I V, 
'c=10mA, 
IF = 0 
15,000 


Transfer 
Ratio 


VF 


Input Diode Static 


IF = 10 mA 
1.5 
1.5 
V 


Forward 
Voltage 


Collector-Emitter 
IC - 125 mA, 
IB - 0, 
IF = 50 mA 
1 


VCEI,o,1 
V 
Saturation 
Voltage 
'C - 10 mA, 
IF -10mA 
1 


Input-fa-Output 


Vin-out 
=:t 1.5 kV. See Note 6 
lOll 
lOll 
n 
'10 
Internal 
Resistance 


Cio 


Input-lo-Output 


Vin-out 
'" O. 
f = 1 MHz, 
See Note 6 
I 
1.3 
1 
1.3 
pF 
Capacitance 


TlL113 
TILl19 
PARAMETER 
TEST CONDITIONS 
UNIT 
MIN 
TYP 
MAX 
MIN 
TVP 
MAX 


" 
Rise Time 
VCC=15V, 
IClonl 
= 125 mA, 
50 


Fall Time 
RL = lOOn, 
See Figure 1 
50 
"' 
If 


" 
Rise Time 
VCC 
10V, 
'Cion) 
- 2.5 mA, 
50 


'f 
Fall Time 
RL = lOOn, 
See Figure 1 
50 
'" 
_. 


PARAMETER 
MEASUREMENT 
INFORMATION 
i---l47n 


----~~----~ 
INPUT 


-::1- 
// 
I 


I 
I 
I 
I 
- L 
.-J 


Adjust amplitude of input pulse for: 


IClonl 
= 125mA 
ITIL1131 
IClonl 
= 2.5 mA ITI L 1191. 


10% 


VOL TAGE WAVEFORMS 


NOTES; 
a. 
The 
input 
waveform 
is supplied 
by 
a generator 
with 
the following 
characteristics: 
Zout 
'" 50 n. 
tr <; 15 ns, duty 
cycle"" 
1%, 


tw• 
100~s 
b. 
The output 
waveform 
is monitored 
on an oscilloscope 
with 
the following 
characteristics: 
tr CO;; 
12 ns, Rin;;;a. 
1 Mn. Cin 
'" 
20 pF. 


TEXAS 
INSTRUMENTS 
INCORPORATED 


POST 
OFFICE 
BOX 
5012 
• 
O"LLAS. 
TEXAS 
75222 


TYPES T1L113. TIL119 


OPTO-COUPLERS 


400 


<l: 
200 
E.!. 


c: 
~ 
100 
:JU 
70 
" 
t>~ 
"0 
40 
uI2 


20 


TlLl13 


COLLECTOR 
CURRENT 


vs 


COLLECTOR·EMITTER 
VOLTAGE 


TILl19 


COLLECTOR 
CURRENT 
vs 
COLLECTOR·EMITTER 
VOLTAGE 


200 


180 


160 
<l: 
E 
140 
.!. 


c:~ 
120 
:; 
IF 
c SO mA 
U 
100 
~ 
~ 


..•.... 


~ 
80 


"0u 
60 
I2 
40 
IB ~ 0 


20 
TA ~ 2SoC 


See Note 7 


0 


0 
0.2 
0.4 
0.6 
0.8 
1.2 
1.4 
1.6 
1.8 
2 


VCE-Coliector·Emitter 
Voltage-V 


FIGURE 
3 


OFF·STATE 
COLLECTOR 
CURRENT 


vs 


FREE·AIR 
TEMPERATURE 


1000 


VCE ~ 10 V 


100 
IB ~ 0 


IF ~ 0 


10 


<l: 
fc: 
~ 
:JU 
B 
u~ 
"0u~.• 
~ 
0.1 


(5 
I 
~ 
0.D1 
.£ 
u 


0.001 
o 


IB ~ 0 
TA ~ 2SoC 


100 
See Note 7 


<l: 
E.!. 
80 
c: 
~ 
:JU 
60 
" 
t>~ 
"0 
40 
u 
I2 


TlL113 


COLLECTOR 
CURRENT 
vs 
INPUT·DIODE 
FORWARD 
CURRENT 


VCE ~ 1 V 
IB ~ 0 
T A ~ 2SoC 


/'" - 
/' 


II 
I 
/I 
/ 


TEXAS 
INSTRUMENTS 
INCOHPORATED 


POST 
OFFICE 
BOX 
5012 
• 
DALLAS, 
TIE",AS 
75222 


TYPES 
Tlll13. 
Tll119 
oPTO-CO UPlE RS 


<l> 
C>e 
"0>c u 
.2°U") 
1;;N 


~ 
II 


'" « 
till- 
~: 


E ~ 
w> 
B B 
U 
<l> 
~ 
> 
0°+:' 
u~ 
I 
<l> 


~a: 


wU 
> 


TIL113 


RELATIVE 
COLLECTOR-EMITTER 


SATURATION 
VOLTAGE 


vs 
FREE·'AIR 
TEMPERATURE 


Ic=125mA 
I--IB=O 


IF=50mA 


----r-- 


T1L113 


TRANSISTOR 
STATIC 
FORWARD 


CURRENT 
TRANSFER 
RATIO 
vs 
COLLECTCR 
CURRENT 
~ 
~ 


VCE = 1 V 
IF = 0 
r- 
r- 


TA = 25°C 
I--- 
rt 
- 
- 
r-I 
r- 


- 
- 
k: 
I--- 


- 
- 
I--- 
I--- 


/ 


- 
I--- 


- 
I--- 


- 
I--- 


- 
- 
- 
I--- 


- 
- 
- 
'-- 
o 
-75 
-50 
-25 


o 
.;;; 
'" 
tI: 
~ 
20,000 


C 
'".= 
c 
15,000 
t 
:JU 
"E 
~ 
o 
u.. 


U.~ 
V; 


Iw 
u.. 
.<:: 


INPUT DIODE 
FORWARD 


CONDUCTION 
CHARACTERISTICS 


o 


o 
0.2 
0.4 
0.6 
0.8 
1.0 
1.2 
1.4 
1.6 
1.8 
2.0 


VF-Forward 
Voltage-V 


FIGURE 8 


TEXAS 
INSTRUMENTS 


''''-COfH-'ORAT 
(0 


POST 
OFFICE 
BOX 
5012 
• 
OAL.l..AS 
TEXAS 
75222 


PRINTED 
IN 
USA 


T: 
(onnot 
aHumt 
0"' 
ruponilbd,', 
fOf 
an, 
<if(l,Il'S 
shown 


0' 
"p'Pltnl 
thaI 
Ihty 
all' 
trt, 
fro"" 
POl'"' 
lI'1fr'"p",rn! 


OPT022 
I/O Module Detail 
Electrical Specifications 


ACINPUT 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
DC INPUT 
MODEL 
MODEL 
MODEL 
MODULES 
IAC5 
IAC15 
IAC24 
IAC5-A 
IAC15-A 
IAC24-A 
MODULES 
IDC5 
IDC15 
IDC24 


AC INPUT 
LINE 
95 to 
180to 
INPUT 
LINE 
10·32 VDC 
VOLTAGE 
130 VAC 
280 VAC 
VOLTAGE 


INPUT 
CURRENT 
10ma 
INPUT 
CURRENT 
32 ma at 32V 
AT RATED 
LINE 


ISOLATION 
2500 Volt RMS 
ISOLATION 
INPUT 
2500 Voll RMS 
INPUT 
TO OUTPUT 
TO OUTPUT 


INPUT 
ALLOWED 
1.5ma 
CAPACITANCE 
8P1 
FOR NO OUTPUT 
INPUT 
TO OUTPUT 


TURN 
ON TIME 
20 Millisecond 
Maximum 
INPUT 
ALLOWED 
2ma 
FOR NO OUTPUT 


TURN 
OFF TIME 
20 Millisecond 
Maximum 
TURN 
ON TIME 
5 Millisecond 
Max 


OUTPUT 
TRANST. 
30 Volts 
DC 
TURN 
OFF TIME 
5 Millisecond 
Max 
BREAKDOWN 


OUTPUT 
CURRENT 
25 ma 
OUTPUT 
TRANST. 
30 Volts 
DC 
BREAKDOWN 


OUTPUT 
LEAKAGE 
100 Microamp 
Maximum 
OUTPUT 
CURRENT 
25 ma 
30VDC, 
NO. INPUT 


OUTPUT 
VOLTAGE 
.4 Volls 
at 25 ma Load 
OUTPUT 
LEAKAGE 
100 Microamps 
Max 
DROP 
30 VDC 
NO INPUT 


LOGIC 
SUPPLY 
4.510 
12to 
20 to 
4.5to 
12to 
20 to 
OUTPUT 
VOLTAGE 
.4 Volt at 25 ma 
VOLTAGE 
DC 
6V 
18 V 
30V 
6V 
18 V 
30V 
DROP 


LOGIC 
SUPPLY 
12 ma 
15ma 
18ma 
12 ma 
15 ma 
18 ma 
LOGIC 
SUPPLY 
4.5 to 
12 to 
20 to 
CURRENT 
VOLTAGE 
6V 
18V 
30V 


LOGIC 
SUPPLY 
12ma 
15ma 
18 ma 
AC OUTPUT 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
CURRENT 


MODULES 
OAC5 
oAC1S 
OAC24 
OAC5·A 
OAC15-A 
OAC24-A 


LINE VOLTAGE 
12to 
2410 
DC OUTPUT 
MODEL 
MODEL 
MoOEL 
140 VAC 
280 VAC 
MODULES 
ODC5 
oDC15 
ODC24 


CURRENT 
RATING 
3 Amps0 
LOAD VOLTAGE 
60V 


RATING 
DC 


1·CYCLE 
SURGE 
55 Amps 
Peak 
OUTPUT 
CURRENT 
3 A 
0 


RATING 
mps 


SIGNAL 
INPUT 
220 
1K 
2.2K 
220 
1K 
2.2K 
OFF STATE 


RESISTANCE 
Ohm 
Ohm 
Ohm 
Ohm 
Ohm 
Ohm 
LEAKAGE 
1 ma Max 


SIGNAL 
PICKUP 
3V 
9V 
18V 
3V 
9V 
18V 
ISOLATION 


VOLTS 
DC 
8V Aid: 
16V Ald." 
32V Aid: 
8V Ald.' 
16VAld.' 
32V Ald." 
INPUT TO OUTPUT 
2500 V RMS 


SIGNAL 
DROPOUT 
1 Voll 
SIGNAL 
PICK UP 
3V 
9V 
18V 
VOLTS 
DC 
VOLTAGE 
8V Ald.' 
18VAW 
28V Aid: 


PEAK 
REPETITIVE 
400V 
500 Volts 
SIGNAL 
DROP 


VOLTAGE 
. 


OUT VOLTAGE 
1Voll 


MAXIMUM 
1.6V 
SIGNAL 
INPUT 
220 
1K 
2.2K 
CONTACT 
DROP 
RESISTANCE 
Ohm 
Ohm 
Ohm 
OFF STATE 
5maRMS 
LEAKAGE 
1 SECOND 
SURGE 
5 Amps 


MINIMUM 
20 ma 
LOAD CURRENT 
TURN 
ON TIME 
500 Microsecond 


ISOLATION 
2500 Volts 
RMS 
INPUT 
TO OUTPUT 
TURN 
OFF TIME 
2.5 Millisecond 


CAPACITANCE 
8P1 
• Allowed 
INPUT 
TO OUTPUT 
o Derate 
.033 Amps 
per degree 
C from 200 C 


STATIC 
200 Volts/Microsecond 
Min 
DV/DT 


COMMUTATING 
Built in snubber 
(will commutate 
DVIDT 
.5 power factor 
loads) 


'Allowed 
__ 
.L_ -= 
.:;.11 
•••. 4'" 
-- •...--- =-- 


5842 Research 
Drive. 
Huntington 
Beach, 
California 
92649 
(714) 892·3313 


High Voltage DC Output Modules 
Fast Switching DC Input Modules 


DC OUTPUT 
MODEL 
MODEL 
MODEL 
DC INPUT 
MODEL 
MODEL 
MODEL 


MODULES 
DDC5-A 
ODC15-A 
ODC24-A 
MODULES 
IDC5-B 
IDC15-B 
IDC24-B 


LOAD VOLTAGE 
200V 
INPUT 
LINE 
4-16 VDC 
RATING 
DC 
VOLTAGE 


OUTPUT 
CURRENT 
1 Amps 
INPUT 
CURRENT 
14 ma at 5V 
RATING 


OFF STATE 
ISOLATION 
INPUT 
---- 


LEAKAGE 
2 ma Max 
TO OUTPUT 
2500 Volt RMS 


ISOLATION 
2500 V RMS 
CAPACITANCE 
8P1 
INPUT 
TO OUTPUT 
INPUT 
TO OUTPUT 


SIGNAL 
PICK 
UP 
3V 
9V 
18V 
INPUT 
ALLOWED 
1 Volt 
VOLTAGE 
8VAld: 
18V Aid: 
28V Aid: 
FOR NO OUTPUT 


SIGNAL 
DROP 
Wolt 
TURN 
ON TIME 
50 Microsecond 
Max 
OUT VOLTAGE 


SIGNAL 
INPUT 
220 
1K 
2.2K 
TURN 
OFF TIME 
100 MIcrosecond 
Max 
RESISTANCE 
Ohm 
Ohm 
Ohm 


, SECOND 
SURGE 
5 Amps 
OUT TRANSISTOR 
30 Volts 
DC 
BREAKDOWN 


TURN 
ON TIME 
500 Microsecond 
OUTPUT 
CURRENT 
25 ma 


TURN 
OFF TIME 
2.5 Millisecond 
OUTPUT 
LEAKAGE 
100 Microamps 
Max 
30 VDC NO INPUT 


·Allowed 
OUTPUT 
VOLTAGE 
.4 Volt at 25 ma 
DROP 


LOGIC 
SUPPLY 
4.5 to 
12 to 
20 to 
VOLTAGE 
6V 
18V 
30V 


LOGIC 
SUPPLY 
12ma 
CURRENT 


1------ 
JlS 
VA( IJ.5Ql VAC 
r 


N 
r'§b..~... 


3 
2- 


)JOtS 
C. " 
I 
'" 


JH 
)If 
·ON 
-j f-o---7>--1 


I'" 


, 
'" 
n"K 
JZ l'i 
ON 
f-o---7~ 
, 


"ON"' 
r' 
, 


J~-J 
." 
H-W 
J'IlI 
"tw'· 
~~ 


I 
,eo 
B·F 
J2>F 
fN1Ol" 
~~ 


'0' 
13-5 
H-S 
~~ 


t'l"' 
J'. 


"" 


J'. 
~,. 


AID 
(H 
1 
T"J' 
JS 
J.' 
" 
~. 


AIO CH 
'20 


~. 


301< 
" 


~ 


AID 
(H.3 
Tl' 
::7- 


"S0~7' 


J7 


APPENDIX 
C 
PROGRAM 
SOURCE LISTINGS 


1 1 
1 


1 .., 
I 
, ., 
1 
J 
_ 


1" 
.1 
F 
1 
1<; 
1 
17 
1 
In 
I 
] 9 
.1 


?f 
, 


2.1 
1 
2? 
! 


7.J 


$'fITLE 
('CO"iTROL 
T/\SK') 
I*~~************~************~~****************t~***** 
* 
This 
task 
h"nr<]es 
the 
contLol 
<H10 Monitoring 
of 
* 


* 
four 
OVEI1 
r.h2rnbt'rs. 
* 


*****************************************************1 
CC~~'ROLST~SKtMODULE: 
Do' 
DEC:UI.RE F.XCH/'NGE~DFSCR f p'lCn 
L TTSRf LLY 
':"1 HUC'. UHF. 
r 


MESSAGE$HEAO 
ADDRESS, 


MESSAGEt~AIL 
ADDRESS, 


TASK$HEAD 
ADDRESS, 


TAS~tTAIL 
~nDRFSS, 


EXCHANGESLINK 
~DDRESS) 
'; 


DECLf..RF 'i'RUt;LITEI:ALLY 
'01' 
F[-j' 
; 


DECLARE 
FALSE 
LITERALLY 
'C0H'; 


DECLARE 
POOLEAN 
LTTERALLY 
'BYTE'; 
DECLARE 
FOREVER 
LITERALLY 
'WYILE 
DECU·RE 
~SGSHDH 
L1 '['EI<ALLY 
, 
LINK 
ADDRESS, 
LENGTH 
lIDDRESS, 


TYPE 
BYTE, 


H~~E$EX 
ADORE~S, 


RESP$EX 
ADDRESS'; 


DECLARE 
i"iSG~D~'srRJ 
PTOR 
L TTEII/I.LLY 
• S'1RUC','UHE ( 
I~SG$HDR , 
HI:I~J\INDER(1) 
bYTE)'; 


1* 
!IMSG.ELT 
- ANALO~ 
INPUT 
REQUEST 
MES~AGE 
FORMAT 
*1 
DECLARE 
A: ;~:"G 
L I TEkALLY 
'~'J'hUCTUHE 
( 
f'lSG$HDR, 
S1'~TIJS 
i'DDRF:;:;S. 


RASE$PTR 
ADDRESS, 


CH~NNELtG~[N 
ADDkESS, 


APRAY$PTR 
ADDRESS, 


CCUN'l' 
!,DCI1ESS, 
ACTUALSCOUNT 
ADDRESS) 
'; 


1* ·ArTYP.ELT 
- lNALOG 
INPU~ 
~ESSAGE 
TYPES 
~I 


DECLARE 
AIREP 
LITERALLY 
t]~f, 
n 
80S 
Ll 'rElit LLY 
• 31 ' , 


PISQV 
LITERALLY 
'J7', 
ATR,~:'J 
Ll TERP.LLY 
,.,l' 
; 


O('(;],'[P 
(n,k) 
byte; 


D(cJ8rf~ 
(~~G~PTH,LaCJ~nU'l') 
cddress; 
Gec1c[2 
(BLOCKr,RLOCKl,BLOCK2,BLCJCK3) 
byte 
extpl.nA]; 
;)(.:cl" re' 
TOr.ERt.!~CF. 
(t.) 
,,·dd ress 
8xtern,,1; 


DeclAre 
TEMP(C) 
2driress 
ext~[112J; 


Dr·c;l.;;re 
~~ETPOTW.!·(II) 
,"dehf'SS 
('xt'!Lni'l; 


Der!i're 
~$AVERAGE(4) 
Address; 


')'.:<'l<'r", 
T$Ll'.ST 
(4) 
•..d(~rl.'ss; 


Drrlare 
T$L/lSTSAVERAGE(f) 
ad~rcss; 


D~c.1Are 
T~t5(") 
;fdrcss; 


D"c]C1re 
TStl:'(") 
<·e1e'ress; 


D"c:e,re 
:"'l'!,'rU~;(") 
byte 
l'xJ:(.'rnill; 


DecJ~rp 
rPT$flSPLAY$LOCK(5) 
address 
LKterni"; 


211 
1 
25 
1 
21=; 
1 
7--; 
1 
. ' 
2f' 
1 
29 
] 
30 
.1 


31 
1 
:<2 
1 


33 


3,1 


35 
::' 
3.'; 
., 


'17 
1 


"8 
2 
~9 
2 
40 
] 


1\1 
2 
/.2 
2 


~ < 
] 


,,~ 
1 


"5 
1 


Mi 


47 


48 


"9 
sr 
1 


DC!C.1iiLC 
TEMP$(,JlL18Rf.I'l'E(~',) 
(leJG/pss 
,-,xtJ·~rn&l; 
Decli'\Lc 
Dlll'<l/'1Y$Exrr'l(~,) 
iJodress 
extern2J; 


Df"' r L~ r e 
'I' FI>1 p~.tC('f·:OU'I'~rxc 
H (r:;) 
.:o,eld I ess 
ex te r nil J ; 


Declare 
RQAIEX(5) 
"rldress 
~xtern~]; 


Drc1arE 
~Sn~EXCH(5) 
~ddress 
external; 


Decl~re 
CONSTAN~$LGCKOUTSEXCH(5) 
&ddre~s 
extelni1]; 


Derlare 
rH'f$STA'IU~;$EXCH(';) 
,-(Je'ress 
,'xternilI; 


DeC1?LC 
ALAR~$MSG 
structure 
(MSGt>HDR); 


O~rlale 
CONVERT 
?i$ms~; 


/* 
This 
term 
is 
used 
to 
convey 
inil'ial 
j'.emperr,tures 
*/ 


DeclaLe 
CAL~TE~P 
bpsed 
MSGSPTR 
structure 
( 


MSG$HDR, 
Cl\L F'ddress 
); 
RQ\-\!AI1': 


Proce~urc 
(EXCH,MESSAGE) 
addless 
~xte(n(1~; 


Declar0 
(EXCH,MESSAGE) 
?d~ress; 


end 
RC'''''\[T; 
RQSEND: 
Procc~ure 
(~XrH,MESS~Gr) 
external; 


Cp.c]?r·· 
(EXCH,I'1ESSACE) 
Ci(~dress; 


en(1 
R(lSEND; 
RQACP'l': 


Pror,~dure 
([XCH) 
",ddr~ss 
!,xt:.>rn(11; 


Cer1are 
EXCH 
Ad~ress; 


enn 
RQl\CP'J'; 


DFc1ArC' 
OVEN~IN$'rOL(4) 
byte 
d.-.~_a 
( 


PIH,P2H,8tH,P8H 
I; 


Dec]?re 
OVE~$CAUTION(") 
byt~ 
d~t~ 
( 


] r B , 2r H , <: nJ , fl (' tl 
); 


Dp~la(e 
OVEN$DANGER(4) 
byte 
~ata 
( 


0.lIi,r2H,rl!H,roH 
); 


[',~r.]i;'re OVEN~()N$MI\SK(I1) 
byte 
('iltc 
( 


(1 J H , f) 2 \j , C t IJ , (1[' Ij 
); 


recl?re 
CVEN$HEATER(4) 
byte 
oatn 


1 ('[ i , 2 (7 H , ~rH , <~nj ); 


Dcc1~r~ 
OVEN$HUN(~) 
byte 
~atn 
Ir~,20H,~VH,RrH 
); 


Dcr.}Clre 
()FF~E1(/.) 
iiGd(~ss; 


Declare 
'I Ai:LE 
(2.5S) 
~odrcss 
,",'td 
( 


200,2rl,2A7,2rl,2C~,2r5,2P~,2~7,2R~,2FO, 
2f\S',71 v, 2J] ,21;:>,2J 3, 21t,,:')5,21 h, 217,2.18, 
719,27~,2~1,222,223,224,225,27~,227,22~, 
??~'1, 23r, 
231, 
~37, 
/~~, 
')J5, 
77(,,237 
I 2~P, 7~9, 
2~r,~~1,2t~,2~t,24~,2t7,2t,D,249,25C,75J, 


;:> <';>, ? 'i <'l, 2~;, 
, 2 ~"' , 2': fl , 2<',9, 
2(; r • ;::'; 1 , ;><; 3, 
2F, '5, 


26r,,7~7,2r,8!2fi9,27r,~7],27~,274,276,27R, 
2 7 ~ , 2 r' C', 7 I') 7 , 2f ,1 , 28 5 , ?f' 7 , 7 ~r , 7 RC , :? 9 c' , 2 (', 
, 


::> <: :: , 29 c; , 29 r, , 2 CJ r , 799 , ~C r. , ..,(; 2 , :' Vt. , 3 r.5, "'r 7 , 
3rD, 
::r,S, :'10,,31;', ~1",:] 
':, :'l!':, 
32V" 
:'22, :'71;, 


?26,328,33r,J32,"'J~,:]r,,<3R.34r,~t2,311", 


~ Jl.::; 1 ?t R , 35 r , ? 5:2 , "")5 t , :-'5 ~ , .-5 p , ~0r , 3Cl2 
, ?(i I' 
, 


3G~,3r,~,37V,:'7?,]7d,"'7G,"7P,?8r,3R2,Jnc;, 
.~~n r , ~~l n , ? ( 2 , :3~ ~. , :: q ('I , I' r (', t r? 
I 
/ 
(A 
:-. 
, l C'~I I t.l 
{.; , 


t]2,rlS,"Jf',~2r,"7~,~2(""78,,,,r,,!~3,~3G, 
t:9,A~1 
,~flt,tft'~,r~l 
,45t,/5~/~~f 
,t~~\/~~~, 


5] 


52 
/. 


~~ 
2 
5~ 
? 
55 
2 
5(, 
/. 
57 
2 


58 
2 


59 
2 


G(, 
:( 


G) 
.' 


(,2 
-, 


M' 
, 


S" 
3 


'-c: 
:1 
>., 


(\G 
3 


(i" 
, 
) , 


r;~ 
4 
.i ~J 
4 


71 
5 


72 
5 
-n 
'! 
71. 
5 


75 
S 
7F, 
" 


77 
3 


78 
" 


€r 
/. 


RJ 
" 


82 
., 


~7r/~~3, 
7~,~~(',/~~,~Cr,~~?,~9~/r:r~,~~( 
,~, 
5 \ "l , ::\1 1 
I 
1 5 , ~ l S , r ;:., 
f 
~:.,~~.., 
, 
~~: 
1., 5 :~.5 , ~t ~', ~11 5 , 


5 5 e , r. r", ~-, 
r, {' , 5 G~), ~ 7 r- , ~)"/ r-. , 
:- f~ (' , sr ~ , r., ~ 
(' 
, 
r.; (' ~, , 
r, r-r , G,,~~'l , 
t ( 
, 
:'=) 1 5 , ~ '} (~ , ()? :. , r,3 C", G:' 5 , -:;I! r , 6 f 5 , 


li5f1., ,,55,6:)(;, 
:;'-5, r,7~\, (:.75, G8r, 
r,P5, 
fiSC, r.;9"i, 


7" f , "7 ( 
~.~I 
- J (' , 7 _15 , 72 ( , 7/5 
, /' ~ V , 7:-;5 , --;I! r , P/4 :' , 


75r,rr0,G~r,r~r,00~,c~r,rrr,rr' 
,rrr,00r, 


(' (1r , r r r. 
, 
(' r r , r r r , ( r r , err, 
r ('( , r r r , ('" f: , "r 
(I , 
orr,0rr,rA0,prr,00r,rrr,rGr,nrr,rr0,rV0, 
0('0, r(~r. rr"" (n', rn, 
rn(.j 
) ; 


1* 
J~iti~ljz2ti0n 
of 
control 
rask 
*1 
CON'I'ROLST/I,SK: 
P!oce~ur~ 
public; 


Output(235)=D1H; 
CONVERT.BASE$PTR=Ef7rrH; 
CONVERTol 
ENGTH=21; 


CONVERT.TYPE=fTSCS; 
CONVER~.R~SP~8X=.AtD~EXCH; 
CONVERT.CHANNEL~CPJN=r; 
CONVERT 
• 1I1~Rl' YS PTn =. ';-Ef" P; 


CONVERT.COUN~=(; 
Do 
fot 
EVE:1 
; 


1* 
~ait 
Ear 
one 
secon~ 
to 
llctpse *1 
~SGSPTR=Rr~A]T 
(.DU~NyeEXCH,2r); 


1* 
Brin') 
in 
(;rtil 
frorl 
~wllchcs 
*1 
BLOCK0=N01' 
INPUT(2J~); 


1* 
Lockout: 
tpmperal:ure 
stornge 
;:-rcC's 
fOI- 
Ur(]. u, "'/ 


LUCKOU'!'=H(;'!A'I IT 
(. TE~'IPSLCCK('U';'~l::xrH, 
(,) ; 


1* Get 
r~w 
~&ta 
from 
pnalog 
~onve[ter 
*1 
C~]1 
ROSEND 
I.RQAIEX,.CONVERT); 


Io1Sc; SPTn=RQWI',JT (•J\SO$EXCH,~;) ; 


/* TerurelC'ture 
cp]i~r~te 
pro~~dul0 
*1 


MSGtPTR=ROACPT(.TEMP~C)\LIBHATE); 
r f 
W;G$PTR 
<> 
r: 


then 
e10; 


k=('; 
Do 
~hilS 
(TABL~(~)<>CALTEMP.CAL 
AND 
k(255) 
; 


k=k+l; 


f'nG; 
Do 
n=0 
to 
:'; 
OFFSET(n)=(TEMP(n)/lS)-k; 


en<1; 


en0; 


1* 
Con v e r t 
6 at,' 
i n to.; 
n CJin,)e r i n<J 
U 1\ its 
* 1 
Do 
Il=~) 
to 
J; 


Jf 
«(TEMF(n)/]~)-nFFrE1(n))~255 
then 
TEMP(n) =('; 


~IS0 
TE~P(n:=TABLE(1EMP(n)/]G)-OfFSfT(n)); 
l~n(~; 


I'~ 
RE~lei~i(' 
],ockout 
of 
~pmrer?turl~S 
*/ 
(';:-1] 
RQSEND 
(.TE~PSLOCKOUTSEXCH.L(CKOUT); 


/* 
Compute 
i1VLr~gc 
t('m~0r2tul~ 
*1 


:1" 
:1 
l.,- 


8<1 
II 


e~ 
1\ 


~17 
r. 
,) 


88 
e. 


89 
') 
S r~ 
-1 
91 
') 


92 
5 


93 
5 


911 
I! 


9') 
4 


9(, 
<1 
SI: 
I! 


SS 
5 
Ire: 
5 


HI 
5 


Jr' ~\ 
I) 


] (14 
f~ 


105 
" 
leF, 
5 


J07 
S 


]('9 
F 


1 
J ~ 
" 
1 lJ 
r; 


1 P 
e, 


113 
~ 


115 
r; 
]11) 
t; 


117 
r, 


lIP 
~ 


I 1 Q 
c', 


1.2] 
5 


1 ?? 
5 
]/~ 
<1 


L?'-: 
S 
, 25 
5 
J 
1211 
5 


Do 
n=C' to 
~; 
TSAVFHAGE(n)=(T$LA 
/* Proicrt 
temp(r~tures 
if 
T$~VEHAGE(n)~=T 
then 
do; 
TSt5(~)=«T$~VERAG~(nl-T$LPST$AVERAGEln))*5) 


+T$LASTSAVERAGE(n); 
TStJG(n)=«(TShVERAGE(n)-T$LPST~AVERAGEln) 
)*lr) 


+T$LAST~AVERAGE(n); 
, 


'l'lrl;+'i'EI'iP(n) 
'I'); 
n t 0 tlL~ [u t u r e */ 
LAST$f\VEI,JlGF:(n) 


(~n6; 


else 
do; 
T5t5(n)=TSLASTSAVERJlGE(n)-((T$LASTSAVERAGE(n) 


-TSAVERAGE(n))*S); 


T $ t ] Ci (n) =TSLAST$,/'VERAGE 
((l) - 
( (l 
$Li'ST$/WF H/\GI: (n) 


-TtAVERAGE(n))*l~); 


end; 


/* 
lJpc'dte 
stored 
r'i'li;l */ 


TSLAGTS~VEHAGE(n)=TtAVERAGE(nl; 
T5LAST(n)=TEMP(n); 


/* 
Test 
for 
~~Live 
ovcn 
*/ 


MSC$PTR=RQWAIT 
(.CONSTANTSLOCKOUT$EXCH,P); 


IE 
(18LCCK0 
AND 
OVENSONSMASK(n) 
)<>V) 


AND 
(TEMP(n)<>r)) 
th'''11 
(10; 


~;'I'A'I'US (n) 
=7; 
RLOCK7=ELnCK" 
OR 
OVCNSRUN(n); 
/* Test 
for 
2n 
intoleri"nce 
=on~ition 
*/ 
If 
SETPOrNT(n)-TOLER~NCE(n) 
< 
T~MP(n) 
~Nn 
SETPOINTln)+TOLERANCE(n) 
> 
TEMP(n) 


then 
(~o; 


STATUS(n)=7; 
BLOCK1=bLOCKl 
nn 
OVEN~INSTOL(n); 
end; 
el se 
BLOCKl =P,LOCKI 
MID 
NOT 
OVE.:NSH1$TOL (n); 


/* Test 
for 
a 
caution 
ronc'ition 
*/ 


If 
Sf1POINT(n)-TOLFRANCE(n) 
> 
TSr5(n) 
OR 


SETPOINT(n)+~OLERANCE(n) 
< T$t5(n) 


t0t:n 
(10; 


ST,l>,'i'US (n) 
=14; 
BLOCKJ=RLOCKl 
OR 
nVEN$CAUTION(n); 
en(1 ; 
e.1s" 
PLOCK] =bLOCKl 
Al~D 
r~OT 
OVF:NSCMJ'I'lL'N (n) 
; 
/* Test 
for 
~ 
f~ng~r 
con~itjon 
*/ 


If 
~ETPOINT(nl-TOLFR~NCE(nl 
> 
1EMP(n) 
Ck 
SETPOINT(n)+TOLERANCE(n) 
< 
TEMP(n) 
~ht'n 
(.10; 


S'l',~,TlJS 
(n) =:' I ; 


BLOCK2=ELOCK2 
0H 
OVEN$OANGEkln); 


(~nr1i 
els~ 
RLOCK7=PLOCK2 
AND 
~~f 
OVENSDANGER(n); 
/ * 
r: i' n r' 1e 
r: 0 n t: r o,~ 
0 f 
he i" t r' r 
'" 1 pme n t: s * / 
If 
SRTPCIN7(n) 
>~St)r(n) 
then 
RLOCK:1=RLOCK:' 
OR 
OVENSHEATER(n); 


c] Sp 
bLOCI<~=8LOCK' 
llND 
NOT 
OVI::NSHENiTR In) ; 
en~; 


else 
clo; 


/* 
Turn 
cverythino, 
off 
whC'n op(:ralor 
shuts 
off 
OV"1l 
*/ 


RLOCX)=RLOCKI 
AND 
N8T 
CVENSIN$TOL(n); 
BLOC];] 
=13Lr)('K1 
AND 
NGT 
UVE:-J$C1IUTl'ONIn) ; 


BLOCK3=RLPCK2 
AND 
NOT 
OVEN$HCATEHln); 


10-59 


J27 
5 


l/'8 
5 


1?9 
5 
nr 
") 
131 
~ 
132 
11 


]'3 
3 
l.V 
~ 
135 
~ 


Ph 
:? 
137 
2 


J ?f' 
1 


RLOCK2=BLOCK2 
A~D 
NOT 
OVEN$DANGERln); 


BLOCK2=BLCCK2 
AND 
NOT 
OVEN$HUNln); 
::;Tl\1'U~;In) =!'; 
encl ; 
C<lll 
nrSENl) 
I.cGN~T}\t'1'SLeC!<LJU'l·$EXCH, 
~lSC$P'l 
H) ; 
enc>; 


/* 
Output 
Oi'lt.", 
to 
rea] 
·",or10 
*/ 


OUTPU'l(73?)=BLOCKl; 
OU~PUT(233)=ELOCK2; 
OUTPUT(234)=RLOCK?: 


enc; 
~nd 
CONTROLSTftSK; 


en~ 
C0NTR0L$TASK$MCDULE; 


CODE 
AHr.A SlZE 
VARJAKLE 
AREA 
SIZ~ 


f<\l\XTiVJl:M 
STACK 
STZE 


/'35 LINES 
HE!\D 
" 
PI,CGRI\J>1 
ER"OR 
(S' 


r S tji)!J 
(Jr' 54H 
erH'()!-l 


23 ','·'r 


rilD 
!iD 


~'fITLEI'C"'J'PM,AME'l£F; Tl\SI<') 
/*********~****~~************~***************** 
* 
Tids 
ti'1sk 
is 
IJ~(~(] 
to 
'-'xnmint' 
r:n(l 
update 
UH 
* 
* 
~pmrcratu[~ 
setpoints 
enC 
toJCI~n"es 
for 
* 
* 
~c:ch 
0 f 
t!l<' 
four 
ovens. 
* 
***************~*****************~************/ 
UPD;\'I'J.:tTAS!(: 
Do; 


$Inc1ucie 
(:pr':col,j[>ICN.EL'l') 
DtCLARE 
TRUE 
LITERALLY 
'0FFH'; 
DE~LARE 
fALSE 
LITERILLY 
'r0H'; 
DECLARE 
BOOL~AN 
LITEHALLY 
~8YTE'; 
DECL!\RF 
FTREVER 
Ll'l'I::RJI.LLY 
'It.'!iI LE 
1'; 
~Includ2 
I:FP:MSGTYP.ELT) 
DEI.LARE 
DtTl-(:TYPE L I'J'~H,l\LLY'r', 
INTSTYPE 
LITERALLY 
'1', 
~ISSEn~INT~TYPE 
LITERALLY 
'2', 


'fl""E~UlJT':'TYPE 
LITERALLY 
,3' , 
FSSREO~TYPE 
LITER,l\LLY '/', 
UC$REOSTYPE 
LITERALLY'S', 
FS~NAKtTYPE 
LITERALLY 
'fi', 
CNTRL$C~TYPE 
LITERALLY 
'7', 
READSTYPF 
LITERALLY 
'8', 
I.LR$RD~TYPE 
LrTERALLY 
'9', 
U\.~;'1'$RDt.TYPE 
I.ITCn/,LLY 'J r' , 
ALARMSTYPE 
LITERALLY 
'II', 
wrITESTYPE 
LITr.RALLY 
'12'; 


Sln~lu~e 
l:tr:~SG.ELT) 


DP.CL\RE 
M~GSHDR 
LJTERALlY 
, 


LINK 
ADDRESS, 
LFNG'I'H 
l,rl,RESc, 


TYP~~ 
RY'J F. 


HCr~l ~EX 
,\DDRES~i, 


RESPSEX 
ADDRESS'; 


DECLl\RE 
~lSG~DESCRJP'i'OH 
LT'lER/lLLY 
'S1R{JrTUHE( 


~ISC;:-HDR, 


REf·11>.TNDER 
(1) 
BYTF)'; 


:::Tnclur.o::; 
(:l'(':']'HfV:SG.ELT) 


DECL!·RE 
TH$jY,~:C 
LJ'l'Eh/\l.LY 
'~'l'HlW'lIJHF' 


/VSGHDR, 
S1',~,1'US 
1\DDRf,:S, 


BUFFER$ADR 
ADDRESS, 


COUWl' 
,~DDl<r:~;;;, 
I\CTUI\L 
[lDDHFSS, 


RE/VI/\JNDF:I, 
(12e). 
BYTE')'; 
DECLARE 
MINSTH$MSC$LENG1'H 
LITERALLY 
'17'; 


:::;r He 1 LI(~'" 
(: 
F r : C HII R. EL1') 


DF,C LJ' HI:' 


NULL 
cor.TROL$C 
CGNTHOUt: 
BELL 
'1'.\8 
LF 
VT 
FE 
CR 
CO.\JTROL$P 
,C,j\"l'Rf:L$Q 
CONTHOLSR 
CONTROLSG 
CO"JTROL$X 
CON',RClL:-7 


ESC 
(HIOTE 
L('/\ 
LC7 
RUBOUT 


LITE:nr-.LLY'('JJl', 
LI~ERALLY 
'('3H', 
LJTERfI.LLY 
'0511', 
LITERALLY 
'V7H', 
LITeRALLY 
'~0H', 
LITERAlL~ 
'rAH', 
LJT~R~LLY 
'('BB', 
LITERI\LLY 
'eCH', 


LTTEI.l\LLY 
'C'DH', 
LITERflLLY 
'U'Jl', 
LI'l'I::HI'LlY 
'lIB', 
LITERALLY 
'17.11', 
LTTE!'I\.LLY'IJH', 
LITERAlLY 
'1GH', 
LITERALLY 
'IMI', 
LJ TFRALLY 
'1 l't!' 
, 
LITERALLY 
'22H', 
LI'fERALLY 
'" 
111' , 
L r T F f-< A L [. Y 
'-: A 1-1 I 
I 


LI TCRlI LL Y 
'7FtI'; 


SIne]u~c 
(:rr:SYNCH.FXTI 


HC'SEND: 
PRCCEDURE 
(EXCH~NcEtrcINTER,MESSAGE~POINTER) 
EXYERNAL; 
J:ECLARE 
(EXCHJl.NGE 
~ POINTER, 
~:ESS/\GC 
<: PCTNTEJl) 
I.DDt·U:S;'; 


R(1W ('.1 T: 
PRC( 
EDUnE. 
(E'XCj,ANGf~SFr'lN,[Eh, 
DELAY) 
l,r,DRESS 
E>:n'HN?\L; 
DECLARf 
(EXCHANCE$POINT~R,DELl\Y) 
ADDRESS; 


17 
'/ 


] r 


19 
..• 
L 


20 
? 


21 


...... 
? 
L' 


2: 
7 
2~ 
J 
25 
J 


2~ 
J 


'J.7 
1 


2!' 
79 
J 


:'l11 
1 


:n 
I 
,... 
1 
- 
L 
3J 
1 
3" 
.l 


J'> 
1 


1(, 


"0 
" ~. 
J 
4:? 
1 
1'] 
1 


44 
/. 


45 
2 
It ,~ 
J 


~7 
2 
It." 
;> 
49 
'- 


5" 
1 


RQACl''f: 
PROe Ef,UKE 
(J::Y.O!lINGE 
tPQI 
WnR) 
!If)\)P.ESS 
EXTERNAL; 
DECLARE 
E~CHANGE£POINTER 
~DDRESS; 


ROISND: 
PROCEDURE 
1IED$PTR) 
EX'i'fRNAL; 
DECL~RE 
IED~PTR 
~DnRRS5; 


EIIID 
R('ISNIl; 
Declprc 
TEMPtC~LIRRATE(5) 
~~~ress 
2xtern~]; 
DecL~re 
UPDATEtEXC'H (5) 
;,d,lress 
ext;Ht\;ll; 
Declare 
CRT~ST/\TlJS~P.XCH(5) cc'c'r<!ss 
extf'rlw]; 
D€'("),~re 
C()MP~EXCH(5) 
a(l~rcss 
L'xternid; 
DecJpre 
CONSTANT$LrCKOUTtEXCH(~1 
a~~r<!ss extern?]; 


Cpcl~re 
RQOUTXIS) 
~~~ress 
Dxt?rnvl; 


Decl~(e 
R0INPXIS) 
;~~res~ 
~xt~rna]; 


Dc~l~rc 
WORDS$EXCH(5) 
address 
ex~prnp]; 
Declare 
SETPOINT(4) 
addlGSS 
external; 


DccJ~re 
TOLERANCEII') 
?rldress 
external; 
Declare 
BUFFEK2 
~ddrpss; 
D~c]are 
MSGtPTR 
Hddress; 


Decli'r>: 
MSC stf 
ucturt:: 
( 
MSG$HDR, 
STATUS 
;;d~res:.;, 
BUFFER$PTR 
oddress, 
rr.UNT 
;'(,dress, 
Ar.TUPL 
~rcress 
); 
D0c]?re 
CAL$TE~P 
stru~turp 


MSG~:fiDR 
, 
CAL 
adr'r0ss ); 
l)(;clrlre 
UPDS,.,.SG cdC'tess; 
DecJ?r~ 
ENERGIZE 
b~S8~ 
UPDS~SG 
structure 
[ 
MSG::HOR, 
STA'fUS 
,~(Id r.:!ss, 
BUFF~RSPTR 
~~~ress, 
COUNT ad(lr'~ss, 
ACTUAL 
~ddress 
); 
Dcclarp 
E~ARLE~MSG 
structure 
MSG$HDR 
); 
De~12(~ RUFfER(Cr) 
byte; 
Dpc12re 
OVEN 
byte; 
DF:C~nEP: 
Proct'c'uri: 
(SQURCE., 
'J'ARGt::T) 
0xter 
n, 1; 
De~l~re 
(SOURCE,T~RGET) 
adr'rRss; 


end 
f\EC~IlEP; 
"~C~2$BINAHY: 
Pror.p.('urp. 
(~OUHC:t:,'1'j\f,CI::T,GIZE) 
byte 
f'xtelnal; 


De<elar<:: 
(SOURCE,T/\RGET) 
c:~drcss; 
Declftre 
8JZ~ 
byte; 


end 
ASCS2$BINARY; 
8<:dilr<~ 
""~G$I 
12r) 
byt(~ 
c'ilti'l 
( 
ESC,'a' ,'ENTER 
eVEN 
NUMBER-'); 


5] 
08('12[e 
I"SG52(?P) 
hyte 
6<1:? 
CH,LF, 
'PNT8E 
NEW 
S~TPOJNT-', 
'XXXX.X-' 
); 
<;2 
Di,r;';-(r' 
MSGS3(20,) 
by",~~ 
(~L'ta 
CR,LF, 
'ENTER 
NEI'i 
','OLE[,f'NCE-', 
'XXXX. X-' 
); 


53 
Dee-InL' 
C'ALJVlfC(17) 
byte 
C;2tF: 


'TE,'1PERATlJRE- 
I 
1; 


511 
DU'1ort' 
r~s('$" 
(I)?) 
hyte 
(:i'tr. 
( 
Cfl,LF', 


I (S'rNrUS- 
(~;), 
PlIRI,i"\E'l'ERS- 
(P), 
CJl.LLfiHATE- 
(e)' 
, 


CR,LF, 
'fNTER 
RE0UES~-' 
I; 


Declare 
WAIT 
]iter21]y 
'MSG$PTR='; 


DccLlre 
F:lR 
1it"r",11y 
'RCltllI'T'; 


Declare 
START 
literally 
'CALL'; 


Dee1 
;=lle 
T"~;K 
J itl'l.'r,11y 
'RC~~FNO'; 
UPD1','l'E: 


Procc(~L1re 
pub] 
ic; 


/~ 
lnitiolize 
task 
~t 
strct-up 
time 
*/ 


Do 
fon"/Ll; 


JVlSr.. RESP SEX =. COI~PSEXC 
11; 
/* 
"-'<"i t 
for 
rcquust 
to 
enter 
t,lSh. 
~ / 
UPD$!"'SG=Rt;'I'I!l\IT 
(. UPDATEtF:XCH, 
CO); 


/" 
Get 
':0sir'c,l 
oven 
number 
['rorr; op'cc,tor 
*/ 


RQST~OVEN: 
MSG.HUf}ER$PTR=.MSC$l; 
M~C.TYPE=WRrTESTYPE; 
I"FG.r.OUNT=7f; 
Stert 
'-"SA 
(.RQOU'l'X,.MSG); 


h'; it 
fOl 
(.CO/'n':EXCI1, 
r); 


/* 
... 
Tnl~IJt 
ne\~ 
numbel 
*/ 
M~·G. BUFf"ER~ P'i'R=. BUFFl::R; 
MSGJCUNT=:'S5; 
MSG. TYPE=C LR ':' 
RD~;TYr'E; 


~t2rt 
t?sh. 
(.RCTNPX,.MSG); 


IAI" it 
for 
(. COi'1P~'E)(CP., r); 


OVrN=(BUFFER(~) 
AND 
0'~)-1; 


If 
eVEN 
>:'l 
then 
(1o:ro nO~TcOVEN; 


/ * [.i sf.' J ,~y 
r c qIH! S t 
,1n(' 
CUI 
~ € n r 
s.: t po i n t *; 
GETtTEMP: 


C',1.1 
] 
I'1OV(, 
(28, 
.",5C:;2, 
.BUFFER); 


Cr,] 
I 
[,Ecc'REI' 
(.SE'rpOTNT 
(ovpn) 
,. 
PUFFER+2.1); 


MSC.TYPE=WRlTEtTYF~; 


iV'SG.CCUNT=7R; 
~';t;'rl: 
tash. 
(.ROOUTX,./·1SG); 


W"it 
for 
(.CCJJ'lIP~F.XCH,(); 


/* 
... 
Inr-ul 
nel, 
Sctl'joint 
*/ 


MSG.TYP£=CLR:HD:;TYPL; 
Sl:~rt task 
(.RQINPX,.MSG); 


\A!, it 
for 
(.COMP:FXCrr,'-); 


If 
ASC$2S8INARY(.8UFFF.R,.EU~FEn2,1)=r 
OR 
BUFYER2 
) 
7rr 


:-I<"fl 
go:~to 
GF.'I$TEMP; 
If 
CUFFER2 
<> 
P 
!'hen 
do; 


l'ii'it 
[or 
(.CONS'I'/,rH'$LOCI<OU'l'trxCH,('); 


SETPOINT(oven)=BUFFEH7; 
su rt 
tesJ.. 
(.CONST/·,W.'~LOCKClJ,,·$EXCH,H~;GtF'i'l{); 
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3 
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:< 
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~In 
:< 


77 
7r1 
3 
79 
~ 


8(1 
, 


f'] 
, 


R2 
, 


[1J 
'. 


2ll 
'3 
85 
J 


~~7 
:< 


PC) 
I' 


% 
I' 
91 
,. 


92 
~ 


9:< 
3 


9.1 
Cl 
95 
., 


91; 
3 


97 
., 


9r. 
3 


99 
3 
170 
3 


IVl 
., 


107 
3 


Jr." 
3 


lrr, 
II 
H'-' 
4 
1('8 
" 
H'9 
,., 


lU\ 
3 


III 
.,., 


112 
.,., 


1.13 
3 
lJ~ 
:< 


115 
:< 


11(; 
3 


lJ7 
3 


1113 
3 


119 
3 


Pl 
:< 


1/:' 
? 


125 
4 


126 
4 
1/7 
.1 


12f 
" 
1/9 
~ 
130 
" 
In 
" 
1:'2 
" 
UCl 
4 


13/ 
" 


135 
" 
)37 


,., 


1::e 
4 


enc; 


/* Dis~12Y 
request 
dnd 
~urrent 
tolerance 
*/ 
GET$TOL: 
. 


Call 
move 
P9,.t-ISG$?,.BUfFEH); 
Call 
DEC$REP 
(.'I'OLERANCE(ovpn),.BUFFER-f?2); 
MSG.TYPE=WRITE$TYPE; 
1\'15G. ClJUNT=29; 
StFtl 
task 
(.RQOUTX,.MHG); 


h~it 
for 
(.COMP$EXCH,n); 


/* ...Input 
new 
loler8nre 
*/ 
MSG.TYPE=CLR$RDSTYPE; 
Sti'rt task 
(.RQINPY.,.Io1SC); 


~'j1itfor 
(.COMPSF.XCb,(1); 


If 
ASCS2$SINARY(.BUfFER,.BUFFER2,J)=B 
OR 
BUFF~R2 
> 
700 


thpn 
go$to 
GET$TOL; 
If 
BUFFER2 
<> 
0 


then 
cio; 
welt 
for 
(.CUNSTAL~T$LOCKUU'!'~EXCH,~); 
TOLERANCE(ovcn)=BUFFER7; 
Sti'lrt ti'sk (.r:ONf-1'flNT~LOCK(,U';:'$E)lCH,W;GSPTR); 


enG; 


/- 
Ask 
op~ratnr 
if 
he 
is 
fjnisheci 
*/ 


REQ~NF.XT: 
MSG.TYPF.=WRITESTYPE; 
MSG.COUNT=t;2; 
MSG.RUfFER~PtR=.MSG$4; 
Stint 
las~ 
(.R00UTX,.r~SG); 


w",it 
for 
(.r~OMP$F.:XCH,C'); 


/* 
•.•Get 
his 
[Psponsc 
*/ 
MSG.1YPE=CLR$nD$TYPF; 
MSG.BUFFER$PTR=.BUFFER; 
Start 
t."sk (.RQINPX, 
.NSG); 


W",it for 
(.CO~'P$EXCH,l?); 


If 
(bUFFERrr') 
O'S' 
I'ND 
SUrFER(,', 
<>'P' 
AND 
BUFFER(0) 
(> 
'C') 
then 
go$to 
RECSNFXT; 
If 
BUFFER(V,)='P' 


then 
go$to 
RQSTtOVEN; 
Tf 
BUFFER(0)='C' 
then 
(10; 
GE'fSCAL: 
MSG.TYPE=~RITESTYPE; 
MSG.COUN'1'=12; 
MSG.BUFFER$PTR=.CALMSG; 
Stert 
tClsk (.RQOUTX,.MSG); 
W2i.t 
for 
(.COMP$FXCH,r); 
MSG.TYPE=CLR$RD~TYPE; 
MSG. !'UFFER$PTR=. EUFFER; 
StF"lt l;;sk (.RCiINPX,.MSG); 
W,.,it:for 
(.COi'",pSEXrH,C); 
If ASC$2~RrNARY(.BUFFER,.BUFFER2,1) 
=c 
OR 
BUPFER?>350 
OR 
HUfFER2<7rG 
then 
go$to 
GET$r~L; 
CALSTEMP.CAL~RUFFER2; 
Call 
ROSEND 
(.TEMP$CALIBR~TE,.CAL$TEMP); 


end; 


l1C 
]'"r 


MODULE 
INFORMATION: 
CGDI: lIHEA 
SIZE 
VARIARLF. 
AREA 
SIZE 


M~XJMUM 
~TA~K 
SIZE 
21).<1 LINP.S 
REA!:' 


r 
PROrHAM 
fRROR(S) 
END 
OF 
PL/M-pr 
rOMPILATION 


nC3H 
rr'7CH 
f'('r"H 


ENERGIZE.TYPC=10~; 
~;t(1r t 
task 
I. CHTU:;T!\TUf~EXCIl, 
UPD:fv1SG) 
; 


('n ("; 


end 
UPDATI::; 


end 
UPDATE~TASK; 


~:TI'I'LE 
I 'CH'J' 
UPD/'.TE 
TASK') 


/***********~************************************ 
* 
This 
task 
is 
uti]iz~~ 
to 
up~~te 
th0 
CRT 
ter- 
* 


* 
mined 
C'iSp'C1y 
willi 
lh,? 
current 
oper,ot.ing 
pi:'r- 
* 


* 
a~cters. 
It 
~i]] 
be 
cnteleC' 
upon 
syt€Q 
st2rt- 
* 


* 
up, 
upon 
operator 
request, 
or 
wh~n 
a problem 
* 


* 
exists 
viith 
.,:;ny of 
the 
i1ctivi'ted 
ovens. 
* 
************************************************/ 
CRT~DATA$MODULE: 
Do; 
q He LUDE ( : f r: S YN( Il. 8)(,') 
R('SEND: 
PROC("flURE 
IE X~H/'.l~GE~P(lI 
Ni LR, 
/'lESSP.GE 
SPO TW,ER) 
EXTERNAL; 
DECLARE 
IEXCHANGEtPOINTFR,MESSAGESPOINTER) 
ADDRESS; 


RQv,/\ IT: 


PROCEr:URE 
IEXCHJ.IIlGESPOI 
N'l ER, 
N:LAY) 
"DDRESS 
EXTERNI'L; 


DECLARE 
IEXCllANGFSPOINTER, 
DELAY) 
f.DDRESS; 


R('I\CPT: 
PROCEI1UHE 
IF:XCHAJ~GF:POJNTEH) 
i\DDRI::SS 
EXTERNAL; 
DE~LARE 
EXCHANGE$POINTEH 
ADDRESS; 


ROT SNL': 


PROCEDUHE 
(IED~rTR) 
EXTERNAL; 


Of'( 
LARF 
lEDtrTH 
ACDHESS; 


END R('f~'N[ 


~INCLUDE 
I:F 
:MSG~YP.ELT) 


DECLARE 
rAT!, 
TYPE 
LI'l'Fr-l' 
LLY 
• (~. , 


INTSTYPE 
LITERALLY 
'1', 
MlSSFDSINTSTYPE 
LITEHALLY 
'7.', 
TIMESOUTSTYPE 
LITERALLY 
'3', 
FS$REQSTYPE 
LIT~R~LLY 
'4', 
UC$REQ$TYPE 
LITERALLY'S', 


FSSN~KSTYPE 
LrTER~LLY 
'6'. 
CNTRLSC$TYPE 
LITERALLY 
'7', 
READSTYPE 
LITERALLY 
'e', 
CLRSRD$TYPE 
LITERALLY 
'9', 
LAST$ROtTYPE 
LITERALLY 
'lr', 
ALARM$TYP~ 
LITERALLY 
'II', 


~RITE$TYPE 
LITERALLY 
'J2'; 


$INCLUDE 
(:fr:EXCH.ELT) 
DECL~RE 
EXCHANGE$DESCRIPTon 
LITERALLY 
'STRUCTURE 
( 


MEGSAGESHEAD 
~DDREGS, 
MESSAGE$TAIL 
ADDRESS, 


TASK$HEAO 
ADDRESS, 
T~SKST~IL 
ADDRESS, 
EXCHANGESLINK 
ADDRESS) 
'; 


$INCLUDE 
(:F0:COMMON.ELT) 
DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARF 
FALSE 
LITERALLY 
'rVH'; 
DECLARE 
BOOLEAN 
LITERALLY 
'BYTE'; 
D~CL~RE 
FOREVER 
LITERALLY 
'~HlLE 
J '; 


SINCLUDE 
(:F0:MSG.ELT) 
DECLARE 
MSGSHDH 
LITERpLLY 
, 
LINK 
ADDRESS, 
LENGTH 
ADDRESS, 
TYPE 
BYTE, 
HOME~EX 
ADDRESS, 
RESP$~X 
ADDRESS'; 


DFCLARE 
MSG$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MSG$HDR, 
RE/llil-.INDER 
(1) 
BYTE:)'; 


$INCLUOE 
(:F~:CHAR.ELT) 


OECLAHF: 


NULL 
CONTROLSC 
CONTROL$E 
BELL 
TAP. 
LF 
VT 
FF 
CR 
CONTROL$P 
CONTHOL$Q 
CONTROL$R 
CONTROL$S 
CONTROL$X 
CON'1'ROLSZ 
ESC 
QUOTE 


LITERALLY'(,PH', 
LITERALLY 
'03H', 
LITERALLY 
'rSH', 
LITERALLY 
'r7H', 
LITERALLY 
'VSH', 
LITERALLY 
'PAH', 
LITERALLY 
'rBH', 
LITER~LLY 
'e-CH', 
LITERALLY 
'rOH'. 
LITERALLY 
'lVH', 
LI1'EHALLY 
'J lH I, 
LITERALLY 
'J2H', 
LiTEHALLY 
'13H I, 
LJ'fERALLY 
'lCH I, 
L17ERALLY 
'lAH', 
L ITER".LLY 
'ISH', 
LITER~LLY 
'22H', 


LeA 
LCZ 
RUBOUT 


LITERALLY 
'~lH', 
LITER~LLY 
'7AH', 
LITEHf>LLY'7FH'; 


~'INC:LUDE 
(:F[/:'IHMf;G. 
ELT) 
DECLARE 
TH~~SG 
LITERALLY 
'STRUCTURE 
( 


MSGHDR, 
ST.\TUS 
ADDHES~;, 


BUFFEH$IIDR 
ADDRESS, 


COUNT 
ADDREf-S, 
!'.C'rU/lL 
ADDRESS, 


REf'1AINDER(128) 
BYTE)'; 
DF:CLIIRE 
f~IN~.TH:?i·"SC$LF.(\IG'I.'H 
LTTE:RALLY 
'J 7' 
; 
T'er-lcre 
HOME li~l'rc;l-y 
'lBH,LlPH'; 
Decla10 
LlSIMAGF(9r) 
byte 
d2t~ 
I 


Hone,Lf,Lf,LF,LE,Lt, 
'TE"lPERI'.TUHE 


'DECHEE;r-; 
C.' 
); 
D~cl~re 
L2$JMAGE(~) 
byte 
~Fti 
Hom~,Lf,Lf,Lf,Lf,Lf,LF,Lf, 
'SETPOINT 
' 
, 


'DEGREE:S 
r.' 
); 
D~c)are 
L3~rMAGE(94) 
byte 
data 
( 
J-loJ~e, 
Lf, 
Lf, 
Lf, 
LF, 
Lf, 
Lf 
, Lf, 
Lf, 
Lt, 
'TOr..I'R/\NCE: 
, 


'DEGREES 
C.' 
); 
Dpclare 
Lt.SIJoIACE 
(75) 
byt" 
('"t"c: 
( 


Home,Lf,Lf,Lf,Lf,Lf,LF,Lf,LF,Lf,Lf,Lf, 
'ST~TUS 
' 
OFF 
OFF 
CFE' 
OFF 
); 


Derl;ne 
CHTSHDR(](;2) 
byte 
(:"to 
IBHf~5H,' 
'OVEN 
STATUS 
DISPLAY', 


Cr,LE,LE,' 
'OVEN-l 


'()VEN-/ 
'OVEN-' 
'OVEN-4' 
, 


Cr,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,LE, 
Lf, 
'TYP8 
ESCPP~ 
TO 
~DJUST 
SETPOIN~S' 
I; 
Dec]are 
BELLS(~I 
hyte 
rlata 


Be] 1 ,Be]] 
,Ee]] 
,B,'] 1 ); 
Declare 
MESSAGES 
(35) byte 
dptp 
OFF 
OK 
'CJlU'I'ION' 
, 


I 
ALARM 
" 


, 
I 
); 
Dec]are 
DISPU\Y$PTRI 
(4) adrlress dilL' ( 
• WOH!<~BUFF~ 
2.1, 
.WOR!<$BUFF+36, 
.1A:ORK$BUFF+4S', 
.\I/ORK$BUFF+52 
); 
Declare 
DISPLAY$PTR2(4) 
2ddress 
d2ta 
( 
••••.•ORI<$BUFF+?5, 
.lAJORK$BUFF+3P, 
.WORK~BUFF+5] 
, 
.\.,OR!<~BUFF+611 
); 
Declare 
DISPLAY$PTR1(4) 
ad~ress 
fRta 
( 
• v-iORI<$BUFF+27, 
• WORK $BUFF+4 
fl, 
.INC:RK$BUFF~ 
5:'., 
.vWRI<SBUFf+1)6 
); 


Declare 
DISPLAY~PTR'(~) 
~dd[lSS 
feta 
( 
.WORKBUFF+3r, 
• WORKbUF 
1"+43, 
• 1,'ORKBUFF+5 
0, 
• WCkIC8lJFF·i(;9 
); 
Dec]ale 
MSG$PTR 
ad~rcss; 
Declare 
MSC 
base~ 
~SG$PTR 
structure 
( 
MSGtIlDR, 
COUN~ 
?rlfress ); 
Dec12re 
STARTF.R(3) 
structur~ 


;~SGSHDH 
); 


Declare 
READ 
structure 


MSGSHDR, 
STI':l'USClr.d 
ress, 
BUFFER$PTR 
~d~rpss, 
COUNT 
ac,<'lress, 
ACTUAL 
2~~ress 
); 
Declare 
DISPLAYSTE~P(4) 
structul€ 
( 
UPPf.R i'c1dress, 
LOWER 
2,.1(1 
ress 
); 


Dee] ore 
DISPLAY$SET 
(4) structure 
( 
LOv,'F.Rad,.1 
ress, 
UPPER 
?Gdress 
); 
Dec]are 
DISPLAYSTOL(4) 
strurturp 
( 
LOWEP. CI(1C1rcss, 
UPPER 
a~c1ress ); 
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1 
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1 
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] 
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1 
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1 


57 
1 


58 
] 


59 
.1 


Gr 
1 


61 
1 


(,2 
1 


fi3 
1 


G4 
1 


65 
] 


61; 
1 


1)7 
1 


1)8 
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6~ 
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7f'- 
1 


71 
1 


72 
] 


73 
] 


71! 
] 
75 
.1 


"IF, 
] 


7",' 
1 


78 
1 


79 
1 


fW 
2 


8] 
2 


Declare 
OVEN$ON(IJ) 
hyte 
d2ta 
( 


rlH,02H,r/!H,08H 
); 
Declare 
OVENSCAUTION(/!) 
byte 
dRta 
( 
lrH,2nj,·1(,H,80H 
); 
, 


Decl~rL 
CRT 
structure 


MSG$HDR, 
STATUS 
i'ddress, 
BUFFERSPTR 
address, 
COUI~T Cld(lress, 
ACT~AL 
addless 
); 
Declare 
CRTLOCK 
structure 
(MSGSHDH); 
Declate 
CRT$DISPLAY$LOCK(5) 
address 
extern~l; 


Dec] a re 
TEI~P$LOCK()U'j'$EXCH(5) 
Address 
cxterllB 1; 
Declare 
CONSTANT$LOCKOUT$EXCH(5) 
ad~ress 
external; 
Declare 
CRTSEXCH(S) 
address 
Extornal; 
Declare 
CRT$STATUS$EXCH(S) 
address 
external; 
Declare 
DUMMYSEXCH(S) 
Qocress 
external; 
Declare 
READSBUFFERSEXCH(S) 
address 
external; 


Declare 
UPDATE$EX~H(5) 
Clddress 
external; 


Declare 
RQINPX(5) 
address 
external; 


Declare 
RQOUTX(5) 
2d,lress 
ext,"rn"l; 
Declare 
RQt,.IAKE(S)address 
ext'ernal; 
Declare 
RQL7EX(5) 
Clddress 
external; 


Declare 
RQL(,EXfS) 
ac.dress 
externa~; 
DEcl;;re 
RQDBlJC (5) "d('ress 
(~xtern<:l; 


Declare 
RQALRM(5) 
Address 
extern21; 
Decl~re 
TEMP(4) 
Nocress 
~xterna]; 


DecJ~rE 
DISPSTE~P(t) 
2('drcss; 


DeclAre 
SETPnINT(~) 
2ddress 
external; 


Declare 
DISP$SETPNTflJ) 
address; 


Derl~re 
TOLEPANCE(~) 
address 
external; 


Declare 
DISP~TOL(4) 
address; 


Declare 
STATUS(~) 
byte 
extern~J; 


Declare 
DISP$STAT(4) 
byte; 
DecJClre 
(BLOCK1,BLOCK2) 
byte 
externi'd; 


Declere 
WORK$BUFF(170) 
byte; 
DeclAre 
BUFFER$A(70) 
byte; 


Declare 
(CHANGE,n,ALARM,NEW,BLANKER) 
byte; 
Declare 
START 
literally 
'call'; 


Declare 
TASK 
literally 
'rqsend'; 
Dec]Are 
WAIT 
liter~lly 
'msg$ptr='; 


Declare 
For 
literally 
'rqwait'; 
DEeSHEP: 
Proced~re(SOURCE,TARGET) 
external; 
Declare 
(SOlJRCE,TARGET) 
address; 


end 
DEC$REP; 
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f13 
2 
f,il 
'2 
PS 
'2 
~r; 
? 
f'''' 
2 
., 


P.8 
2 
89 
1 


<)1' 
? 
91 
.., 


9'3 
:3 


911 
3 


9f) 
/I 


°8 
/I 
O0 
il 
,,- 
I PI' 
,; 


leI 
4 
H? 
11 
1('3 
;I 
H''' 
,; 


1 (' 5 
,., 


If'"] 
t 
lrP, 
11 
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11 
II r 
,., 
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CRT$OATA$TASK: 
Procerur~ 
puh1j~; 
/* 
Tniti~]izp 
systpm 
~t 
starL-up 
time 
*/ 


Start 
task 
I.TEMPSLOC~OUTSEXCH,.STtRTERIVII; 


S ti'J rt 
tc: skI. 
CONSTAN'l' ~L.OC K~lUTSE:XCIl, 
• S'f b RTER 111 I; 
STARTER 
12 I .1'YPE=l0C'; 


~)tc'l 
t 
t?sk 
1JRT$STATUS$FXCfl, 
.S'1'JlRTJ-:R (7.; I; 
CR1.RE~P$EX=.CRTSF.XCH; 


/* 
Perform 
110in 
CRT 
',i2it 
*/ 


Do 
for0ver; 
f':;'it 
for 
(.f)Ui"'MY::F:XCII,H~I; 
w,~it 
for 
I.CR'J'~STJI,TUS$EXCH,0); 


If 
M~:C.TYPE=255 


then 
AL.'\RM= 1 ; 


e1s,? 
ALARM=,; 
/* 
Output 
heafing 
*/ 


If 
IMSG.TYPE=lrV 
OR 
0SG.1'YPE=255) 


then 
('0; 


T f 
l\Ll\RJV=~ 


th0n 
c&'1 
RQSENDI.CRT~DlSPLl\YSLOC~,.CkTLOCK'; 
CRT.~YPF.=~~JTE$TYPE; 
CRT.COUNT=1,)?; 
CRT.BUF~ER~PT~=.WORfSHUrf; 
READ.TYPF.=CLR$ROSTYPE; 
READ.cnUNT=?C:;5; 
RF.An.RESP~EX=.REAO$BUFFER$EXCH; 
nr:AD. 
BliI FEHSPTR=. 
E'U~'E ERI'; 
If 
JlL,\RM=C' 
then 
start 
task 
I.RCTNPX,.READ); 


C"l] 
ffiO',lC 
(P'2,.CRT$HOR,.I·~ORK$BUFF); 
('ell 
move 
(~fi, 
.CHT"HDR+"2, 
.WOHKSI3UFF+82); 


~t.;'rt 
tAsk 
(.RQOU'l'X,.CHTI; 


Wait 
for 
(.CRTSEX('H,P); 
NEl-i=1 
; 


f'nd; 


/~ 
Test 
for 
chan0~ 
in 
t0rnper~ture 
of 
Any 
oven 
*/ 


CHANGE="; 
"';it 
for 
I.TEMI'~L(lCKOlJTSE)lC'H, 
r); 
Do 
n=~: 
t.o 
..,; 


1 f 
'l'f,~lP In) <>GISP~Tf;'~P 
(n) 
then 
CHANGE=1; 


enc>; 
Ci'll 
mov" 
18,.TEMP,.DISP$TF"lPI; 


~tart 
tAsk 
1.'l'EMPSLOCKOUTSEXCH,~SGSPTRI; 
/* 
When 
() 
r.hAllgC 
exists 
bui 
2Cl nt"',' 
1ine 
*/ 


If CHANGE 
OR 
NEW 
th0n 
(10; 


C;lJ 
move 
(9r,.L1srf'l'l"C:E,."'CRK~BUFF); 
1:'0 n=r 
to 
~; 
CaJ 
1 
Cf,C$kl:P 
1 .n1.SP$TE(~P 
(n) 
, OISPLAY~P'i'RJ 
In)); 


end; 


/* 
Output 
ne-, 
tcmp •.'rature 
line 
to 
CWf */ 
CRT.TYPE=WRTTESTYPE; 


CRT. 
COUNT=£!?; 


129 
II 


110 
" 
III 
<1 


1:->2 
1 
133 
? 
'3" 
3 


135 
<1 


137 
<1 
1?3 
3 
139 
3 


1-10 
3 


111? 
" 
143 
4 
Jill! 
5 


,11' 5 
') 


It'(, 
Ll 
11'.7 
<1 
11! 8 
-1 
]110 
4 
J 5C' 
~ 
151 
I! 


IS? 
, 


.IS? 
3 
1St'! 
3 
155 
~ 


157 
~ 
158 
3 


159 
~ 


16r. 
:' 


1~2 
4 
11.13 
11 
1'14 
5 
][)5 
r; 


l"iG 
11 
1r.7 
IJ 
l"iR 
<1 
l!i9 
il 
17~ 
11 
171 
4 


172 
3 
173 
? 
174 
3 
]75 
~ 


Start 
task 
(.RQOUTX,.(:RT); 
Wait 
for 
(.CRT$EXCH,Vl; 


enc.; 


/~ 
Test 
for 
ch~nge 
in 
OV0n 
setpoints 
*/ 


CHANGE=I' ; 
Wait 
for 
(.CONSTANT$LOCKOUTSEXCH,n); 
Do 
n='" to 
3; 


If 
SETPOINT(n)<>DISP$SETFNT(n) 
then 
CHl\NGE=l; 
end; 
C~.Il 
move 
(8,.SETPOINT,.DISP$SETPN1); 


Start 
task 
(.CONSTANTSLOCKOUT$EXCH,MSC$PTR); 
/* 
Build 
nl~\i line 
•..1Ien 
,"" change 
\.as 
detected 
*/ 
If 
CHl\NGE 
OR 
NEVe 
then 
(lo; 


Ci'lJ 
move 
(92, 
.L?$IMAGE, 
.v.iORKBUFF); 


Do 
n=0 
to 
~l; 
Cf·11 
f1ECSREP 
(.DTSP$SE'l'PNT(n) 
,DISPLI\y$P1'R2 
(n»); 
cnn; 


/i 
Output 
sp.t:poi:1t 
lin(' 
*/ 


CR7.TYPE=~RITE$TYPE; 
CRT.COUNT=S9; 
CRT. FUFF EH:~PTR=.j'CRl{!3 UFr ; 
St?rt 
task 
(.RCOUTX,.CRT); 


Wcdt 
for 
(.CwrSEYCH,r); 


end; 


/* 
Test: 
for 
r.htlnge 
i n 
t-:o~erilnce 
] i:1(, */ 
CHANGE=V1; 
"ri',it 
for 
(.CONSTp.N'j'$LOCV.OUT~,EXCH,0); 


Do 
n=C 
to 
3; 


If 
TOLERANCE(n)<>OJSP$TOL(n) 


then 
CHANGE=1; 


cnc1; 
Call 
move 
(8,.TIJr.ER~.NCE,.r.ISPSTOL); 


StF.rt 
task 
(.eONS'lANT$LCeKOUT~EXelJ,I1SG~~PTR); 


/* When 
chnnge 
is 
found, 
huild 
new 
line 
~/ 
If 
CIJANGE 
OR 
NEW 


then 
do; 


Co)] 
move 
(94,. 
L?$IjvIJIGE, 
.wORKS8UFF) 
; 


Do 
n=G:' to 
?; 
eft)1 
DEC~REP(.DISP$TOL(n)~DrSPLAY$PTR2(n)); 
end; 


/* Output 
t:o~erznce 
line 
*/ 


CRT.TYPE=WRITESTYPE; 
eRT.COU~T=91; 
CRT.BUFFER$PTR=.~ORKBUFf; 
St?rt: t?sk 
(.RQOUTX,.CR~); 


~ait 
fOI 
(.CRT$FXCH,e); 


end; 
/* Build 
S~2tus 
~essage 
*/ 


CHANGE:=0; 
~~it 
for 
(.CONSTl\NT$LOCKOUT$EXCH,01; 
Do 
n=(1 to 
3; 


If STATUS(n)<>DISPS~Tl\T(n) 
then 
CHANGE=:; 


177 
4 
178 
3 


J79 
~ 


18(11 
:3 


1£12 
4 
'8:' 
11 
J8Ll 
5 


]RS 
5 
18n 
l 
187 
Ll 
188 
to 
189 
~ 


190 
J 


] 91 
3 


]93 
Ll 


195 
5 
196 
5 
] 97 
5 
19P 
t1 


199 
5 


7rJ 
5 
7r2 
5 
2V:l 
5 
2r" 
5 


;> ('5 
I' 


? (-'() 
:3 
7CQ 
7- 
2011 
] 


end; 
Call 
move 
(Ll,.ST1\TUS,.DISPSc;TlI'I'); 


Start 
t~sk 
(.CONSTANT$LOCKOUT$EXCH,~SCSP'I'R); 
/* Output 
to disp]~y 
*/ 
If CHANGE 
OR 
NE~ 
then 
co; 


Ci'1J 
move 
(7c;,.LI'Ii~I\GI:.,.hOR":~BUH); 
Do 
n=(:'too :'; 
Ci'11 
mo'l(' (7, 
.MES~;JlGE~'+OISPSSTAT 
(n) ,DISPLilY$PTk' 
( 


em] ; 
CHT.COUNT="!":;; 
Stalt 
tClsk 
(.R('OUTY,.rR'J'); 
tr.i":,il 
for 
(.CRT$ExrH,('); 


enc1; 


/* lest 
for 
request 
too exit 
this 
mO~L 
*; 
MSG$PTR=ROACPT 
(.RFJlD$BUFFERtfXCH); 
If 
.l'·.LI\RM=f1 
then 
c10; 


If 
(MSG$PTR 
<> 
r 
<'1l0 
EUilER!"('" 
= 
IFH~ 
then 
co; 


M~·.CSPTH=F·,Q\~1IJT 
(.rkTtOJSPLJlY$LOCK, 
(); 


stRlt 
t~sk 
(.UPD1ITE$EXCH,MSGSPTR); 


enc'; 
else 
do; 
If 
MSGSP1'R=r 
then 
STARTER(7) 
.TYPE=20F; 


else 
C~ARTER(2) 
.TYPE=1pr; 
SUrt 
task 
(.CRT$STATUSSEXCH,. 
ST"H'n~h 
(7) ) ; 


NE\-J=0 ; 


('no; 


enc; 


nnc; 


en~ 
CRT$D~TASTASK; 


end 
CRT$DATA$MODULE; 


MODULE 
INFCRMATION: 
CODE 
AREA 
SIZE 
Vl\R lAB 
LE 
ARE" 
5 I Z E 


MAXIMUM 
STACK 
SIZE 


:'PP.LJNr.S 
READ 


(11 
PROGRAM 
ERROR(S) 


(772rH 


01i?9H 
~N'''H 


Jfl7/D 


~(\3D 
t)D 


? 


!' 
" 
/ 
5 
2 
r, 
2 


"1 
? 
8 
;> 


S 
2 
10 
2 


1J 
3 


1/ 
3 
1:' 
;> 


1" 
;> 


15 
3 
l{) 


") 


IP 
!' 
F 
!' 


$TITLE('ASCII 
STRING 
TO 
FIXED 
BTNARY') 
1************************'*************************** 
* This 
program 
converts 
an 
AFCII 
string 
into 
A 
fix- * 
* 
ed 
point 
binary 
nu~hEr. 
The 
fixed 
~ecim~l 
point 
* 
* 
is determirwo 
by 
the 
pClrameter 
pnssecJ in SIZE. 
* 
********************************************'*******1 
ASCS2$BINARYS~ODULE: 
Do; 
1* SPECIAL 
ASCII 
CHARACTE~S 
*1 
DECLARE 
NULL 
CONTROL$C 
CONTROLSE 
BELL 
TI\P. 
LF 
V'1' 
FF 
cn 
CONTROLSP 
CONTROL~Q 
CONTROL$R 
COWi'RCU:S 
CONTROL$X 
CONTROLS? 
ESe 
QUOTE 
LCA 
Lr;;: 
RU80UT 


LI'l'ERALLY 
LITERALLY 
LITERl,LLY 
LI'rERJ\LLY 
LITERALLY 
LITERALLY 
LITEHALLY 
L TTERALLY 
LI'l'EHALLY 
LITERALLY 
LITERALLY 
LI'l'ER1'LLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LfTERALLY 
LITERALLY 
LITF:RALLY 


'?0H', 
'CJH 
f 
I 
'()5H' 
, 
1(,' 7H I , 
'~9H' 
, 


I c;1AH', 
''''BH', 
'0CH 
I, 


I rOB 
I, 
'1 0H I 
, 
'11 H ' , 
I J 7H I , 


I J 'H ' , 


I ISH' 
, 
'lAH' 
, 


I ISH' 
, 


r 27H' 
, 
';;1 H' , 
'7 AIl· 
, 
'7FH 
I ; 


l,SC~'? 58 IN.l'.RY: 
ProcLdure 
(SRC$PTR,TRGT$PTR,ST7E) 
byt~ 
public; 


D~~lal0 
(SRC$PTR,TRGT$PTR) 
a~dress; 
D('c.lare (SCURCE 
b"s(!d SRC$PTH) 
('31') 
byte; 


DeC":l<'lre 
RESULT 
/),seclTRGT$PTR 
address; 


Declare 
(N,SI7E,K,DP,DIGJ'fS,Vl\LlD) 
byte; 
Dec!?re 
POWER(6) 
a~dress 
dat~ 
( 


~,J,Je,Jr,(~,HHr,lr("(f' 
); 


1* Find 
loc~tion 
of 
dpcima1 
point 
'I 
n=C; 
['0 
while 
~OUflCE:(n)<>'.' AND 
,C1URCEln)<>CH 
AND 
SOURCE(n)<>LF; 
n=n+l; 


end; 
DP=n; 
1* Provi(lp rorrcct 
number 
of rligits to 
right 
of ciecimi'l ~'I 


Do 
n=r 
to SIZE; 


SOURCE(DP+n)=SOURCE(DP+n+l); 
If SOURCE(DP+n»~9H 
OR 
SOUflCE(DP+n)<lVH 
thpn 
do 
k=n 
to 
PIZE; 


SOURCE(DP+~)='r'; 


r.;nr; 


2r, 
3 


21 
2 


27- 
2 
/.3 
2 
2.:1 
3 


;:>f) 
1 
?7 
;:> 


29 
2 


Jr 
2 


<2 
3 
13 
1 


311 
" 


~5 
'11 


3'l 
" 
"27 
4 


30 
3 


39 
7- 
40 
2 
41 
1 


e n<l; 


/* Mark 
ene 
of 
string 
*/ 
DIGITS=DP+SIZE; 


/* Test 
for 
?lJ 
vali~ 
characters 
*/ 


VALID=l; 
Do 
n=0 
to 
DIGITS; 
If 
SOURCE(n»3~H 
OR 
SOURCE(n)<3rH 
then 
Vl\LID=0; 


end; 
If 
DIG fTS>S 


then 
Vl\LID=r-; 


/* Convert 
~atc. to 
binary 
ano 
store 
*/ 
n=0; 
If 
VALJD=1 


then 
do; 
RESULT=U,·; 
Do 
~hile 
DIGITS> 
F; 
RESULT=RESULT 
I- ( ( 
S(lURCE(n) 
AND 
rFH) 
* 
POWER(DIGIT2)); 


n=n+1; 
DIGITS=DIGITS-l; 


end; 


enrl ; 


/* Return 
to 
calling 
p[ogra~ 
*/ 


Return 
VALID; 


end 
ASC$2$BINARY; 


end 
ASC$2$BINARYSMODULE; 


CODE 
AREA 
SIZE 


V~RIABLE 
AREA 
SIZE 
MAXTMUM 
STACK 
SIZE 


8r 
LINES 
READ 


a PROGRAM 
ERROR(S) 


('178H 
??,rJlH 
0001lH 


37f)D 


IrD 


IlD 


1 


2 
1 
:1 
] 


<'1 
1 
5 
1 


f) 
] 


7 
1 
e 
I 
~ 
1 
10 
1 


tTITLE('rOMMON 
VARIA8LE 
STORAG~t) 
I*****************************~*************~****** 
* 
This 
mo~u]p 
cont~ins 
those 
v~ri~hles 
common 
to 
* 


* 
multiple 
tasks 
in 
the 
oven 
control 
Appli~ation. 
* 


**********************.***************.***.*******/ 
VARIAFlLE$STCRAGE: 
Do; 
Declare 
SETPOINT(4) 
a~dress 
public; 
Declare 
TOLERANCE(~) 
arldr~ss 
public; 
Decla[c 
TEMP(4) 
aduress 
public; 
Decl2re 
STATUS(4) 
byte 
public; 
Declare 
BLOCKf 
hyte 
public; 
Declare 
BLOCKl 
byt~ 
pUbliG; 
Declare 
BLOCK2 
byte 
pUblic; 


Declare 
BLOCK3 
byte 
public; 


end 
VARIABLE~STORAGE; 


CODE 
ARE/'.SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
If; LINES 
READ 


~ 
PROGRAM 
EHROR(S) 


0N'r", 
N'2f'H 
~rrrH 


~n 


3?D 


0D 


1 


;> 
1 


3 
2 


4 
2 
5 
2 
h 
7. 


7 
;> 
8 
2 


Cj 
7. 


H 
1 
11 
3 
12 
2 


J3 
2 
14 
3 
15 
1 
1'1 
:- 


J7 
2 
18 
.., 


?r 
3 
?l 
1 


2/ 
? 
23 
2 
7." 
2 
25 
'2 
26 
1 


STTTLE('WORD 
TO 
ASCII 
CONVERSION') 


1**************************************************** 
* 
This 
routine 
converts 
a 
fixed 
point 
word 
in ~em- 
* 


* 
ory 
into 
a 
4 digit 
plus 
I decimal 
ASCII 
disp12y- 
* 


~ 
~ble 
numher. 
Zero 
blanking 
is 
included. 
* 


****************************************************1 
DE(,SREP~',NI('DULE 
: 
Do; 


DrCSHEP: 
Procedurp 
(SOURCE,TARGS'I') 
pub'ir 
; 


D€cLJrl' 
(SOURCE,TARGE1) 
address; 


~ec]ere 
ANSWR(S) 
byte; 


Dec]are 
(DISPLAY 
baser 
TARGET) 
(5) byte; 


Drelare 
NUMBER 
based 
SOURCE 
structure 
( 
ELEMENT 
,rcress 
); 
Dee] ;on' 
N byle; 


Dec'are 
CJ\LC(5) 
C1ocJress; 


/* 
Tnitii1lize 
*/ 
Do 
Il=P to 
4; 


A ISWR(n)='f'I'; 


end; 
CALC(F)=NUMBER.ELEMENT; 


1* 
ConverL 
to ASCII 
*f 
Do 
n=l 
to 
5; 


CALC(n)=CALC(n-])/J0; 
ANSWR(5-n)=(rALC(n-l) 
mod 
10) 
+ 
JFH; 
end; 


1* Perform 
zero 
bJ~nking 
*1 
Do n=~J to 
3; 
If 
/\NSv~R(n)<>'(;" 
then 
n=4; 


else 
ANSl'iR(n)=' '; 


eno; 
f* 
Format 
with 
oecimal 
point 
*/ 


call 
move 
(-:,.l\N~WR,'fl\RGET); 
OrSPLAY(4)='.' 
; 


DISPLAY(~)=l\N:,WR(~); 


end 
DEeSHEP; 


end 
DEC$REP$MODULE; 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
4(1 LINES 
RF.I'.P 
o 
PROGR~M 
ERROR(S) 
OF 
PL/M-rA 
CO~PILATION 


(l0EEH 
((' PH 
00rllH 


23RD 


700 
"0 


intel~ 
APPLICATION 
NOTE 


I. INTRODUCTION 


The utilization 
of computers to provide cOlltrol or 


monitoring 
functions 
for industrial 
processes 


frequently 
results in complex computer systems. 
Distributing 
the control and processing 
intelli- 


gence throughout 
the co.ntrol network 
reduces 


significantly 
the complexity of the system while 


increasing 
the reliability. 
The physical 
areas 


being controlled or monitOred by each portion of 
the distributed 
system will generally consist of a 


relatively 
small number of 110 functions which 


are related by some control algorithm. 


The Intel iSBC 569 Intelligent 
Digital Controller 


(IDC) 
and 
the 
iSBC 
941 Industrial 
Digital 


Processor (IDP) are a part of the expanding line of 
Intel products which are oriented toward filling 
the requirements 
of these systems. This applica- 


tion note deals with the use of these devices to 
provide control of a closed loop system using a 
version of the PID control algorithm. 


It is assumed that the reader is familiar with the 
basic concepts required to generate software and 
has had some experience with using a computer. 
This application 
note will then guide the reader 


through a typical application, explaining in detail 
the decisions 
which must be made in order to 


effectively utilize a microcomputer 
to provide a 


control solution. 


The 
application 
which 
has 
been 
chosen 
is 


considered to be typical of the type which lends 
itself to control. The mechanical 
aspects of the 


application 
will be explained so that the user not 


familiar with the particular machinery will be able 
to understand 
the development. 
It will be seen 


that the techniques 
used will apply to any other 


specific application. 


The emphasis 
of the note will be on the use and 


implementation 
of the hardware 
and 
software 


features 
of the digital 
processor and controller. 


The actual 
PID control 
algorithm 
will not be 


developed in this application 
note. 


Reasons 
for Intelligent 
Boards 


The advent of microcomputers 
and the resulting 


trend 
toward 
utilizing 
these devices to control 


processes has resulted in many cases where the 
over'all system 
performance 
has deteriorated 


because of the demands placed on the processor. 


In these applications, 
the computer has become 


overburdened 
with 
control 
algorithms, 
alarm 


detection, communications, 
and the many other 


tasks required of it. The processor can be inter- 
rupted by time dependent tasks to the point where 
other processing tasks can not be completed. 


Presently, 
Intel 
provides 
two 
110 expansion 


boards which are capable of handling 
portions of 
the 
processing 
load 
which 
formally 
required 


processor time. These two devices are the iSBC 
544 Intelligent 
Communications 
Controller 
and 
the iSBC 569 Intelligent Digital Controller. 
Tasks 
which involve communications 
or parallel digital 


110 
can 
now be offloaded 
without 
requiring 
valuable 'processor time. These boards can issue 
interrupts 
to the 
master 
or host 
processor 
if 


interaction 
with 
other 
processes 
or devices is 


required. This technique greatly increases system 
throughput 
by offloading 
the other bus master 


processors 
and 
by minimizing 
traffic 
on the 


Multibus system bus. 


In some cases, it will be found that the intelligent 
controller can function to control the process in a 
stand-alone 
environment, 
providing 
a more 


functional, low cost control system. 


The concept of offloading 
the processor 
of its 


input/output 
tasks can be developed on the iSBC 


569 controller through the use of slave processors 
which may be installed on the board to assist the 
host. The result is the ability to provide up to four 
processors on a single intelligent slave I/O board 
by using the concept of slave processors. 


The On-Board 
Slave Concept 


The utilization 
of the iSBC 569 controller' 
is 


enhanced 
through 
the use of On Board Slave 


processors 
(OBS). These devices distribute 
the 


system intelligence and offload the processor on 
the intelligent 
controller. 
They 
can 
provide 


custom digital interfaces with the various devices 
which may be connected to the 110 ports of the 
controller. 
The OBS device allows a designer to 


fully specify his control/interface 
algorithm in the 


peripheral 
chip without 
relying 
on the master 


processor. Three types of OBS compatible devices 
are available from Intel. These are: 1) Industrial 
Processors, 2) Standard 
UPI devices, and 3) UPI 


8741A for custom applications. 
By combining the 


devices in various combinations, 
optimum solu- 


tions 
can 
be generated 
for different 
control 


applications. 


Before proceeding, we should cover the general 
characteristics 
of the OBS devices available 
for 


use in conjunction with the iSBC 569controller. 
It 
will be seen that careful selection ofthe proper 110 
controller chip can reduce significantly 
the design 


effort required to provide a control solution. 


II. BASIC UNIVERSAL 
PERIPHERAL 


INTERFACE 
DISCU8ISION 


With the introduction of the Universal Peripheral 
Interface, 
Intel 
has 
expanded 
the intelligent 
peripheral 
concept by providing 
an intelligent 


controller that 
is fully user programmable. 
The 
8741A is a complete single-chip 
microcomputer 


which connects directly to a master processor data 
bus. 


To fully understand 
the techniques 
used by the 


UPI 
8741A devices, 
we must 
have 
a general 


knowledge of their characteristics. 
Only then will 


we feel comfortable 
in implementing 
a design 


which uses the components. 


Hardware 
Features 


Each Universal Peripheral Interface has lK bytes 
of program storage plus 64 bytes of RAM memory 
for data storage. It has a powerful, 8-bit CPU with 
a 2.5 JLseccycle time and two interrupts. 
Over 90 


instructions 
are 
provided 
in its instruction 


set. Most instructions 
are single byte and single 


cycle and none are more than 
two bytes long. 
These instructions 
are optimized for bit manipula- 
tion and I/O operations. 
Special instructions 
are 
included 
to allow 
binary 
or BCD arithmetic 
operations, 
table lookup routines, 
loop counters, 
and N-way branch routines. 


The chip's 8-bit interval timer/event 
counter can 
be used to generate complex timing sequences for 
control applications vr it can count external events 
such as switch 
closures 
and position 
encoder 
pulses. Software timing loops can be simplified or 
eliminated 
by the interval 
timer. If enabled, an 


interrupt 
to the CPU can occur when the timer 
overflows. 


Two 8-bit bidirectional 
I/O 
ports are included 


which are TTL compatible. Each of the 16 port 


lines can individually 
function as either input or 
output under software control. 


The UPI microcomputer 
is fully supported 
with 


development 
tools. The combination 
of device 
features and Intel development support make the 
8741A an ideal component for low-speed periph- 
eral control applications. 


Software 
Interface 


The OBS communicates with the processor on the 
host board by means of data transfers between its 
registers 
and 
the 
host 
board's 
data 
bus. 
A 


communication 
protocol has been defined which 


provides a set ofrules by which the processors may 
interact 
with each other. Two types of software 


protocol 
are currently 
defined. 
These 
are the 
"simple" 
and the "extended" 
protocol. 
Before 


attempting 
to utilize 
the 
OBS devices 
in an 


application, the concepts used for the communica- 
tions must be fully understood. 


When used on one of Intel's single board compu- 
ters, the communication 
path is by means of the 


110 ports on the host board. This means that two 
port addresses, an odd and an even location, are 
assigned to each OBS device. The even numbered 
port 
is used 
to transfer 
"data" 
between 
the 


processors. The odd numbered portis used to write 
commands 
into the OBS and to read its status. 


Each 
transfer 
between the host and the slave 


device consists of the movement of eight bits of 
information. 


Four of the eight 
bits 
available 
in the status 


message 
have been given predefined 
functions. 


The bit will be set (logical 1)when the correspond- 
ing condition exists within the OBS device and 
will be reset (logical 0) when the condition does not 
exist. The functions of the four bits are: 


Bit-D. Output Buffer Full (OBF). 


This bit indicates 
that the OBS has placed 


information 
into the transfer 
register 
and 


that the information 
is available to the host 


processor. It can be read by performing 
an 


input operation from the even numbered port 
assigned 
to the particular 
OBS. When the 


data has been read, the bit will automatically 
be reset to indicate that no data is available. 
As we will see, this is one of the key features 
enabling 
efficient 
utilization 
of the host/ 


slave relationships 
on single board compu- 
ters. 


Bit-I. Input Buffer Full (IBF). 
This bit is used to indicate that data has been 
placed into the input transfer register by the 
host device and that it has not yet been read 
by the slave. Data is transferred 
into the 
input register by means of the host perform- 
ing an output to the even numbered port ofthe 
OB8. The bit will be reset when the device 
reads 
the 
data 
from 
the input 
transfer 
register 
into its accumulator. 
Data 
should 
only be output to the OB8 when the IBF bit is 
reset! 


Bit-2. FO Flag. 


Unlike the IBF and the OBF bits which are 
controlled by hardware, the FObit is control- 
led by the device 
software. 
The normal 
function of the flag is to provide a lockout to 
prevent 
the host from sending 
more data 
until the previous data has been processed or 
the operation is complete. 


Bit-3. F1 is the Command/Data 
Flag. 
It is automatically 
set when the host sends 
either a command 
(odd numbered 
port) or 
data 
(even 
numbered 
port). 
A logical 
1 
indicates that a command has been sent and 
a logical 
0 indicates 
that 
data 
has 
been 
sent. This bit may also be cleared or toggled 
by the UPI software. 


These bits will provide normal communications 
between the master and slave processors. 


Figure 1 shows the sequence of operations which 
can be used by the host processor to establish 
communications 
with an OB8 using the simple 
protocol. In Figure la, we see that all operations 
are initiated by the host. It will first verify that the 
IBF flag indicates that the input register is empty 
and 
available 
for receiving 
a command. 
The 
command 
is then 
sent 
to the odd numbered 
port. This command will inform the OB8 that is to 
perform 
some task. 
The task 
may 
involve 
a 
requirement for more information to be sent to the 
controller 
and it may involve 
the controller 
returning some data to the host. Figure 1b shows 
the operations required for receiving data from the 
OB8. 


~y 


With these 
ideas 
in mind, 
we can move to a 
discussion 
of representative 
versions 
of the 
devices available for use on the IDC boards. 
We 
will then look at a typical application to see how 
they can actually be applied to solve a problem. 


Standard 
Universal 
Peripheral 
Controllers 


Intel presently 
manufactures 
three UPI control- 
lers for non-industrial 
applications. 
These are: 


1. 8278 Programmable 
Keyboard Interface 


2. 8294 Data Encryption 
Unit 
3. 8295 Dot Matrix Printer Controller 


These devices offer an "off the shelf' 
solution to 
many applications 
which might be encountered. 


The Intel 8278is a general purpose programmable 
keyboard 
and 
display 
interface 
device. 
The 
keyboard portion can provide a scanned interface 
to 128-key 
contact 
or capacitive-coupled 
key- 


boards. The keys are fully debounced with N-key 
rollover and programmable 
error generation 
on 


multiple new key closures. Keyboard entries are 
stored in an 8-character FIFO with overrun status 
indication when more than 8-characters have been 
entered. 
Key entries 
set an interrupt 
request 
output to the master CPU. The display portion of 
the 8278 provides a scanned display interface for 
LED, incandescent, 
and 
other popular 
display 


technologies. Both numeric displays and simple 
indicators 
may be used. The 8278 has a 16 x 4 


display RAM which can be loaded or interrogated 
by the CPU. 
Both right entry calculator and left 


entry 
typewriter 
display 
formats 
are possible. 
Read and write of the display RAM can be done 
with auto-increment 
of the display RAM address. 


The Intel 8294 Data Encryption Unit is designed to 
encode and decode 64-bit blocks of data using the 
algorithm 
specified in the Federal 
Information 


Processing Data Encryption 
Standard. 
The DEU 


operates 
on 64-bit test words using a 56-bit user 
specified key to produce 64-bit cipher words. The 
operation 
is reversible; 
if the cipher 
word is 
operated upon, the original test word is produced. 
Because 
the 8294 is compatible 
with the NBS 
encryption standard, 
it can be used in a variety of 
electronic funds transfer 
applications 
as well as 


other 
electronic 
banking 
and 
data 
handling 
applications 
where data must be encrypted. 


Finally, 
the 
Intel 
8295 Dot Matrix 
Printer 


Controller provides an interface to the LRC 7040 
Series dot matrix impact printers. 
It may also be 
used as an interface to other similar printers. 
The 


chip may be used in a serial or parallel comm unica- 
tion mode with the host processor. Furthermore, 
it 
provides internal 
buffering of up to 40 characters 
and contains 
a 7 x 7 matrix character 
generator 


which accommodates 
64 ASCII characters. 


Industrial 
Digital 
Processor 


Intel produces 
the iSBC 941 Industrial 
Digital 


Processor (IDP) which is programmed 
to handle 


an 
assortment 
of typical 
industrial 
digital 


interfaces 
and transducers. 
The controller 
can 


function to provide any of the following: 


1. Scan up to 16 inputs for a change of state. 
2. Provide up to 8 gated one-shot outputs. 
3. Provide eight gated outputs with program- 
mable pulse widths and periods. 
4. Provide monitoring of up to 8 input lines for 


event sensing or as a programmable 
divider. 
5. Provide 
the period measurement 
of up to 


eight inputs. 
6. Provide a frequency to count conversion of 


one input. 
7. Provide for the control of a stepper motor 


having up to eight phases. 
8. Provide 
a simplex 
asynchronous 
serial 


input. 


9. Provide 
a simplex 
asynchronous 
serial 


output. 


In 
addition 
to providing 
one of the 
above 


functions, the IDP can also handle simple parallel 
I/O through the unused port inputs or outputs. 


III. 
FUNCTIONS 
OF THE INTELLIGENT 


DIGITAL 
CONTROLLER 


The iSBC 569 Intelligent 
Digital Controller (IDC) 


is a versatile 
digital I/O processor. 
The IDC is 


designed to operate in a system using anyone 
of 


the following three modes: 


1. Intelligent 
Slave 


2. Stand-alone 
System 


3. Limited Bus Master 


Additional power is obtained by the utilization 
of 


three OBS's to generate 
up to 48 parallel 
input/ 


output data lines. 


In the intelligent slave mode, the controller's RAM 
is shared 
between the on-board 8085A and the 


Multibus users via a dual-port controller. 
Thus, a 


single bus master can control several intelligent 
slaves 
using 
the dual-port 
RAM as the major 


communications 
path. 
Switches are provided on 
the board to allow the user to reserve 1K bytes of 
RAM for use by the 569's processor 
only_ This 


reserved memory is not accessible via the Multibus 
system 
interface 
and does not occupy any bus 


address space. 


In the stand-alone 
mode, the entire system can 
consist of a single IDC, with cables, power supply 
and 
enclosure. 
An IDC can be installed 
at a 


remote site as a completely autonomous 
system. 


The IDC may also be operated 
as a limited bus 


master 
when 
it is the only bus master 
in the 


system. 
Expansion 
memory and I/O boards may 


be connected to the IDC via the Multibus system 
bus to increase the input/output 
capabilities. 
This 


mode could be used to configure one IDC as a bus 
master 
with 
additional 
IDC's 
as intelligent 


slaves. This mode is not available with any other 
bus masters such as iSBC single board computers, 
disk controllers, or DMA devices. 


Input/Output 
Functions 


The I/O interface between the iSBC 569 Intelligent 
Digital 
Controller 
and the external 
devices 
to 


8253·5 
PROGRAMMABLE 
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which it is to be connected normally consists of 
various OBS devices. Each of these slaves has the 
ability to provide sixteen individual input and/or 
output 
lines. 
In addition, 
each provides 
two 


specialized input lines. The IDC is designed to 
accommodate 
up to three slave devices, so the 


normal I/O configuration ofthe board will consist 
of 48 digital data lines. If the specialized lines are 
considered, 
this 
number 
could 
be raised 
to 


54. Sockets 
are provided 
for the insertion 
of 


drivers or terminators 
for use on the 48 digital 


lines. The 6 special purpose lines can only be used 
as inputs and are provided with pull-up resistors to 
terminate the input signals. 


The 
driver/termination 
socket 
configuration 


limits the grouping of the I/O lines to be in groups 
of four. Any slave data line being used for an input 
must have its output latch placed into a logical! 
state so as to allow the input line to be controlled 
by the external signal. 


IV. APPLICATION 
EXAMPLE 


An example of the iSBC 569 controller 
in an 
application 
will help to explain the techniques 


used 
to implement 
a control 
system 
and 
to 


interface 
between the various functional 
units. 


The application chosen will consist of a typical use 
but will be simple enough to allow the design 
operations to be easily followed. 


Suppose we choose to design a control system 
which will be produced as a subsystem to interface 
with and control a liquid applicator. 
As we go 


through the steps required to design and imple- 
ment such a control system, we will see how the 
various hardware 
and software tools which are 


available from Intel can be utilized to allow easy 
"implementation of the task. 


Before proceeding, we will spend some time to 
insure there is a clear understanding 
about the 
definition 
of the liquid applicator. 
When this 


definition is complete, the design of the control 
subsystem can begin. 


A liquid 
applicator 
consists 
of two functional 


parts: 
a device 
to control 
the flow of a solid 


material, 
and a device to control the flow of a liquid 


onto the material. 
We will actually be controlling 


two continuous 
process loops which are related by 


an input parameter 
which specifies the percentage 


of liquid to be applied to the dry material. 


Figure 
3 shows 
the components 
making 
up a 


typical 
weighbelt 
feeder. 
The operation 
of the 


feeder is straightforward. 
The vertical 
gate is 


adjusted 
manually 
to provide 
a desired 
gap 


between the conveyor belt and the lower portion of 
the 
gate. 
This 
will 
result 
in 
a nearly 
level 


distribution 
of material 
on the belt when 
it is 


moving. 
The weighbelt is connected to a load cell 


to provide information 
back to the control system 


giving 
the amount 
of weight on the belt at any 


instant. 
If we know the speed ofthe conveyor, itis 


simple to compute the amount of material flowing 
through 
the feeder during any time period. This 


flow rate is known as the Mass Flow and is usually 
expressed 
as pounds 
per minute. 
The control of 


the feeder system can be provided by varying 
the 


belt speed until the desired 
flow rate has 
been 


obtained. 


Our control system will be designed to control the 
belt speed and to monitor the weigh belt weight and 
any other parameters 
which we determine will be 


necessary to control the flow of material. 
A typical 


control process will require an optimum flow rate 
be established 
for each 
material 
of a different 


density. 
With a known material 
flow through 
the 


feeder, we can go about the process of applying the 
liquid flow to the material in order to complete our 
application 
example. 


The second loop ofthe example will involve adding 
the liquid to the material 
coming from the feeder 


mechanism 
described 
above. 
Normally, 
the 


percentage of material to be applied is fixed by the 


formula or mix design of the product which we are 
manufacturing. 
However, 
since 
the flow rate 
through 
the weigh belt feeder can and does vary 


(our first control loop will not always be able to 
exactly control the flow due to many conditions 
beyond 
our control), 
the liquid 
setpoint 
will 


constantly be changing as a function of the actual 
mass flow and the liquid percentage. 


Figure 
4 shows 
the liquid 
application 
piping 
diagram 
for the liquid 
portion 
of the control 


system. The items with which we will be directly 
concerned are the liquid flow meter and the control 
valve. 
The other components, 
while requiring 


consideration in an actual implementation, 
will be 


ignored in this 
aplication 
note for the sake of 


clarity. 
Let us consider the details of each control 
loop in more depth before we attempt to design the 
control system. 


Mechanical 
Specifications 


In subsequent portions involving development of 
the control system, we will be constantly referring 
to data regarding the mechanical specifications of 
the liquid applicator 
system. Therefore, we will 


establish 
a set of theoretical 
technical 
specifica- 
tions for our system. Later, we will see how close 
the control system can come to providing a control 
which meets or exceeds these parameters. 
These 
specifications will be broken down into two sets of 
data, one for physical parameters 
over which we 
have 
no control, and a second for the desired 
control characteristics. 


The physical 
data provides information 
on the 
mechanical 
design and will be used for guidelines 


in selecting interface equipment and in preparing 
software algorithms. 
The physical data is: 


Operating 
Belt Speed - 
1.1 to 180 feet per minute. Adjusted 
by a 
variable speed motor directly coupled to the 
belt pulley mechanism. 


Feed Output Rates - 
Adjustable 
over a 10:1 range with a maxi- 
mum output of 960 pounds per minute. 


Feeder Belt Characteristics 
- 
The belt will be 9 inches wide by 2 feet in 
length when installed. 
The belt pulley rollers 
will have a radius of 4.5 inches. 


Feeder Weight Sensor - 
The weigh belt feeder will incorporate a strain 
gauge load cell to measure the weight on the 
belt. Its linearity 
shall provide 0.1% of full 
scale range. 


Liquid Flow Rates - 
The liquid flow rates shall vary between 10.0 
and 120.0 pounds per minute. 


The desired 
operating 
characteristics 
of our 
control system will provide the following general 
responses: 


Feeder Accuracy - 
1%of full scale over a 10:1range. The feeder 
will maintain 
the set feed rate within 1% of 
full scale over anyone 
minute period. The 
minimum sample must be at least one pound. 


Liquid Accuracy - 
1% of full scale over the operating 
range. 
Must be able to track mass flow variations 
within the above limits. 


These specifications 
will provide guidelines 
for 
the 
decisions 
which 
we will 
later 
make 
in 
providing a micro-computer control solution to the 
weigh belt feeder application. 


Interface 
Requirements 


A logical place to begin the consideration 
of the 
control system design is to examine the interface 
requirements 
and define the characteristics 
ofthe 
interfaces which will be required to implement the 
control. 
We will consider 
each element 
of the 
physical system separately. 


Weigh belt Weight 


The weigh belt weight will be sensed using a lever 
system connected 
to a load cell integral 
to the 
mechanical 
unit. The output of a strain 
gauge 
load cell is a low level (approximately 20millivolts 
at full scale) analog output. Obviously, this signal 
must be somehow converted into a digital level 
before we can use its information 
to compute the 
actual mass flow across our weighbelt feeder. Our 
design process must define the characteristics 
of 
the digital signal so that the appropriate analog to 
digital 
converter 
system 
can be chosen. 
The 
design path can take any of several equally valid 
approaches, 
any of which will provide a func- 
tional 
control system. For the purposes of this 


application 
note, we will assume that the design 
path 
will utilize the Intel iSBC 569 Intelligent 
Digital Processor. 


This assumption requires us to utilize only signals 
which can be generated 
or interpreted 
using the 
computer board and its associated OBS's. Wewill 
not be capable 
of handling 
an analog 
signal. 


Since some type of signal conditioning 
would be 
required of the low level analog voltage anyway, 
this does not impose any serious restrictions 
on 
our design. Indeed, it will cause us to consider a 
technique which provides excellent noise rejection 
characteristics. 
We will assume that a voltage to 
frequency converter (VIF) will be installed 
near 
the load 
cell and 
the frequency 
will then 
be 
transmited 
over a pair of wires to our digital 
interface. 
Commercially 
available 
converters 
provide a frequency output which varies between 0 
and 
10 kilohertz. 
With this 
in mind, 
we can 
continue with the development of the interfaces 
required in the application. 


The load cell transducer 
will incorporate 
a local 
unit 
which 
generates 
a pulse train 
whose fre- 


quency is proportional to the weight upon the load 
cell. This mechanical 
arrangement 
is typical of 
many gravimetric feeder systems in use today. 


For purposes ofthis application, it will be assumed 
that 
the system 
will be calibrated 
such that 
a 
weight 
of 10.00 pounds 
on the weighbelt 
will 
produce a pulse train 
frequency 
of 10 khz. No 
weight on the belt will generate a frequency ofless 
than 30 hertz. The accuracy of the pulse output 
will be guaranteed 
to beproportional to the weight 
within 
0.05%. Again, 
this is typical 
of devices 
available 
and in general use in similar applica- 
tions. 


The characteristics 
we have described above fall 
within 
the performance 
range 
of the iSBC 941 
processor when operated in its frequency to count 
mode. If we assume a sample rate of 200 msec 
(this value should provide an adequate 
control 
characteristic 
since 
it is unlikely 
that 
the 
mechanical 
equipment 
can 
respond 
rapidly 
enough to warrant 
a faster control and sample 
time), the frequency count read by the iSBC 941 
counter will range between 6 and 2000. System 
accuracy 
of reading 
the belt weight 
will thus 
exceed 0.1%ofthe 
full scale weight reading. 


We will discuss the electrical and programming 
interfaces 
in subsequent 
sections of the applica- 


tion note. 


Weighbelt 
Motor Control 


The flow on the weighbelt will be controlled by 
changing 
the speed of the belt movement. 
Since 


the weigh belt is mechanically 
designed to main- 
tain a constant 
bed level, the amount of material 


flowing will thus be adjusted. 


The belt speed has traditionally 
been adjusted 


using either SCR controllers or by using variable 
transmissions 
between the motor and the con· 


veyor belt. The increased utilization and develop- 
ment of stepper motors is leading toward greater 
use of direct stepper motor drives. This is the mode 
which will be utilized for this application. 


The manufacturer's 
specifications 
for the weigh- 


belt indicate that the following requirements exist 
for driving the device: 


REQUIRED TORQUE - 
149 LB-IN-IN 


REQUIRED MAX SPEED - 
2.54 REV/SEC. 


Referring 
to typical 
manufacturer 
specification 


sheets for stepper motors, we find the torque vs. 
speed characteristics 
shown 
in Figure 
5. Our 


application 
requires 
2.54 revolutions/sec 
which 


translates 
to 508 steps 
per 'second 
when 
the 


stepper is used in a 1.8 degree per step mode. We 
can see that the requirements 
fall well within the 


capabilities 
of the particular 
motor. 


At this point, we have four routes which may be 
pursued to actually interface with the motor. These 
are: 


1. Utilize the iSBC 941 stepper mode to drive 


the stepper motor directly. 


2. Utilize the iSBC 941 frequency generation 
mode to drive a standard 
stepper translator. 


3. Utilize parallel outputs to provide a digital 


output to a stepper translater. 


4. Utilize a 4-20ma. current signal to a stepper 
translator. 


Three of the above modes use a translator 
to drive 


the 
motor. 
If possible, 
we should 
strive 
to 


eliminate the cost of this intermediate 
device. 


Again, 
we will refer 
to the published 
motor 


specification 
sheets. For our typical 
motor, the 


data is shown in Figure 6. The requirement 
for 


providing 
in excess of six amperes per winding 


exceeds 
the capabilities 
of the output 
drivers 


which can be installed on the iCS 930 termination 
board. We will be forced to either design a custom 
high power driver board or to use a translator 
module. To keep the application 
as simple 
as 


possible, we will choose the latter. 


Molor 
Time for 
DC 
Amperes 
Reslslance 
Induclance 


Type 
One Slep Volls Per Winding 
Ohms 
Millihenries 


Ourtype 
1.7 msec 
2.3 
6.1 
0.37 
2.4 


We have three choices left when the decision has 
been made to use a translator 
mod ule. The use of a 


current output mode will necessitate 
the use of an 


external 
analog board. This is undesirable, 
both 


from the standpoint 
of inter board communication 


requirements, 
and from a cost effective basis. 


The use of a parallel output would commit many of 
our output 
data 
ports 
and would require 
the 


installation 
of UPI modules or iSBC 941 modules 


to get the parallel 
output 
drivers. 
In addition, 


parallel 
digital input is not a common option of 


commercially available translators. 


This leaves us with the use of a variable frequency 
output 
to provide 
stepping 
information 
to the 
translator 
module. This is a normal operational 
mode of the iSBC 941 processor and the required 
508 hertz is within the normal output range of the 
device. 


A definite 
advantage 
of our decision to use a 


stepper motor drive for the weighbelt is that we do 
not have 
to maintain 
accurate 
feedback 
and 


control 
algorithms 
to maintain 
the conveyor 
speed. Only a simple check need be made to verify 
that 
the conveyor has not stalled. The stepper 
motor will inherently 
maintain 
a speed propor- 


tional to the frequency rate. 


The actual electrical and programming 
interfaces 


will be discussed in subsequent 
sections of this 
application 
note. 
. 


Weighbelt Speed Measurement 


We have mentioned that a control system using a 
stepper 
motor 
for speed 
control 
can operate 
effectively in an open loop configuration. 
How- 
ever, since a faulty 
component 
could result 
in 
failure of the motor to run, we must verify that the 
belt is indeed moving. This is easily accomplished 
by adding 
a magnetic 
sensor to the weighbelt 
rollers and counting the pulses generated 
as the 
device operates. 


Typical magnetic 
sensors 
and ring magnets 
for 
installation 
on the weighbelt will provide us with 
ten pulses per revolution of a belt pulley. Since the 
pulley is operating 
at a maximum speed of 2.54 
revolutions per second, we will receive between 0 
and 25.4 counts per second. Using 
our sample 
period of 200 milliseconds, this means that we will 
count between 0 and 5 counts during each time 
interval. 
Our decision to use a stepper control loop 
rather 
than 
a conventional 
closed loop seems 
justified as we would obtain rather poor control 
with feedback having this poor of resolution. 


We must make a decision to determine how the 
speed will be sensed by the control board. An 
obvious choice would be the use of an iSBC 941 
processor operating 
in the period measurement 
mode. This would require using our third socket 
on the iSBC 569 host board and would leave us 
without the ability to use an additional 
device to 
support the liquid control loop. We should seek an 
alternative 
solution. 


.The iSBC 569 controller board provides an 8253 
programmable 
interval 
timer. A first approach 


might 
be to attempt 
to configure 
one of these 


counters to provide an event counting mode and 
read the 'belt speed from the counter. However, 
this is not possible since we would be required to 
zero the 
counter 
after 
each 
reading 
and 
the 


counter does not load the preset count until a clock 
pulse is present. 
We would have no ability 
to 


distinguish 
between no belt motion and the belt 


motion which is the same as the previous reading! 


An alternative 
approach 
is to create a software 


counter by routing the belt movement pulse to one 
of our interrupts 
and creating a program which 


will increment 
a counter. Each time a count is 


sensed, the software 
will increment 
a memory 


location by an increment which corresponds to the 
speed represented 
by one count. 


Again, 
we will 
delay 
the 
discussion 
of the 


electrical 
and 
programming 
interfaces 
until 


subsequent 
sections of this application 
note. 


Liquid Flow Control 


The design of a control system to provide control 
of flow through a liquid valve is an integral part of 
the liquid pipe and plumbing design. To optimize 
the system operation and provide a system at the 
minimum 
cost, the integration 
of control 
and 
mechanical 
design must be made. 


Several possibilities exist when making a decision 
as to which control valve to use in adjusting 
the 
liquid 
flow rate. 
The 
actual 
selection 
of the 
physical valve mechanism 
should be based upon 


the 
characteristics 
of the 
liquid 
flow. This 


decision is outside of the scope of this application 
note and will not be pursued. However, the valve 
actuator 
is a device which becomes an integral 
part of the control system and its selection is a 
function of the control system design. 


Figure 7 shows the common control valve types 
which are used to vary the flow rate of liquids. 
The automatic 
control system we are designing 
precludes the use of a manual valve, so we must 
make our selection between the air actuated and 
the motorized control valve. 


Classical control design has utilized air actuated 
valves almost exclusively. This type of actuator 
incorporates 
an intermediate 
transducer 
to 
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4-20 MA 
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convert the signal generated by the control system 
into a variable 
air pressure. This air is used to 


drive a pneumatic control actuator. 
Two types of 


electrical to pneumatic 
transducers 
are in com- 
mon use. The most prevalent 
converts a 4 to 20 


milliampere control signal into a proportional air 
signal. The second type will accept a 0 to 10 khz 
pulse train and convert this to an air output. 


Both 
of the above 
systems 
provide 
excellent 
electrical 
noise 
immunity 
and give reliable 
operation 
in industrial 
environments. 
They do, 
however, have 
disadvantages. 
A supply 
of air 


must be present at the control devices and this air 
must be maintained 
such that it is free from water 


and 
oil. In 
many 
cases, 
this 
presents 
costly 


installation 
and maintenance 
considerations. 
The use of computerized control systems has led to 
a recent concept of eliminating 
the intermediate 
conversion and using instead a digitally control- 
led actuator. 
A stepper motor can be connected to the actuator 


of the control 
valve to provide 
a simple 
and 


economical 
control 
path. 
The control 
outputs 


from the PID control loop can be sent to the iSBC 
941 processor's command queue and the controller 
will handle the motor movements. 


The electrical and programming interfaces ofthis 
interface 
will be fully discussed 
in subsequent 


sections. 


Liquid Flow Measurement 


The use of a liquid control valve to vary the liquid 
flow cannot in i~self provide an accurate control 
loop. Because the pow rate through a fixed valve 
will vary with material 
densities, temperatures, 


and pressures, 
we must provide some type of 


feedback 
into 
our control 
algorithm. 
Thus, 
a 


flowmeter must be inserted into the liquid flow 
and its output returned to the system. 


The control 
system 
designer 
can choose from 


several types of flow meters depending upon his 
requirements. 
Figure 8 shows many of the more 


~ 


~ 
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standard 
classifications 
of flow meters. 
Our 


selection of the meter must take into account the 
type of electrical 
interface 
available 
from the 


meters. 
In our attempt 
to maintain 
a digital 


system which does not require additional support 
boards, 
we will reject 
the 
use of a magnetic 


flowmeter because this type of meter provides an 
analog 
type of output which would require the 


addition 
of another 
board 
into 
our 
control 


system. The wobble meter provides a digital pulse 
type output but its accuracy tends to discourage its 
use in a refined control loop. We will utilize the 
turbine meter for our liquid flow application. 


The output of a turbine meter is a low voltage, low 
current AC signal whose frequency is proportion- 
al to the liquid flow rate. The manufacturers 
of 


the meters provide pre-amplifiers 
which convert 


the signal into 10 volt peak to peak square waves 
which 
are equivalent 
in frequenacy 
to the AC 
pulses. The operating frequency ranges typically 
from 100 to 1200 pulses per second. 


It is desirable 
to measure 
the flow rate using a 
single iSBC 569 controller. 
If we consider that a 


200 millisecond control interval will be used, the 
flow will result in a reading of between 20 and 240 
pulses per sample period. These readings could be 
performed using an iSBC 941 processor, but we do 
not have the socket available for a fourth module, 
so we must consider utilizing 
another 
interrupt 
driven software counter as was done with the belt 
speed. 


All control 
and 
monitoring 
equipment 
for our 


liquid control application has now been defined in 
such 
a manner 
as to be compatible 
with 
the 
utilization 
of a single 
iSBC 
569 controller 


board. 
The 
actual 
interfaces 
to perform 
the 


interconnections 
and to provide control instruc- 


tions can soon be considered. 


Operator 
Interface 


Finally, we must define the data communications 
which 
must take place between the controller, 
other system tasks, and the operator. 
Let us first 


consider the system control variables and the data 
which, if generated by the control process, might 
be useful to the remainder 
of the ~ontrol system. 


The first variable 
which comes to mind is the 
liquid flow setpoint. 
If we consider 
the entire 


control system, this parameter 
will be found to be 


actually 
expressed 
as a percentage 
of the total 


output material. 
For example, if we assume the 


recipe required the final product to consist of 5% 
liquid by weight, we would require that our control 
system add the correct amount of liquid to perform 
this task. 


To allow 
maximum 
flexibility 
of the 
control 
system, 
we should 
allow 
selection 
of various 
density 
materials 
onto the weigh belt. A host 


processor 
with computational 
capabilities 
can 


calculate the optimum gravimetric feeder flow rate 
for the materials 
being combined. 


The control system 
can provide an integration 


function 
to allow totalization 
of the amount 
of 


material 
which has been transferred 
through the 
system. A capability of outputting 
the amount of 


material which has passed over the weigh belt and 
the amount of liquid added will be included. 


The implications 
of the parameter 
storage 
and 


generation 
will be dealt 
with 
later 
when 
the 


host/slave 
relationships 
oftheiSBC 
569 controller 


are discussed. 


Interface 
Summary 


We have defined the required interfaces which will 
be needed to perform our control task. These can 
be grouped into external 
and internal 
interfaces. 


The external interfaces are those which connect to 
physical pieces of external equipment. 


These are summarized 
in Figure 9. The internal 


interface relates to the data which is to be passed 
between the iSBC 569 Intelligent Slave board and 
other 
boards 
which 
may 
be present 
on the 


MULTIBUS 
system 
bus. These data 
areas 
are 
shown in Figure 10. 


We have 
now defined the various 
components 


which we will'utilize 
on the controller 
board to 
support 
the physical 
control and monitor 
hard- 


ware. Our next task is to provide an interface 
between the controllers and the equipment which 
we are to control. In so doing, we will define the 
hardware 
110 assignments 
for the iSBC 941 


processors and for the counters which we will be 
utilizing. 
The following 
paragraphs 
will deal 


with the optimization 
of this configuration. 


• ••• 
DEVICE ••••••••• 
WEIGHBELT MOTOR 
WEIGHBELT WEIGHT 
WEIGHBELT SPEED 
LIQUID VALVE 
LIQUID FLOW 


•••• 
SIGNAL TyPE······· 
•••• 
BOARDELEMENT········ 


10 VDC PULSE 
iSBC 941 
10 VDC PULSE 
iSBC 941 
110 VAC PULSE 
8259A INTERRUPT 
5 VDC MULTIPHASE 
iSBC 941 
10 VDC PULSE 
8259A INTERRUPT 


Figure 9. Control/Monitor 
Signals 


••• 
INPUTS •••••••••••••••••••• 
OUTPUTS •••• 
GRAVIMETRIC FLOW 
ACCUMULATED SOLIDS 


LIQUID PERCENTAGE 
ACCUMULATED LIQUID 


Figure 10. Communication 
Signals 


Controller Interface 


Good design 
practice 
dictates 
that 
we should 


provide 
optical isolation 
between the controller 


and the external equipment when designing for an 
industrial 
environment. 
The optical isolation 
is 


included if we utilize the Intel iCS series of signal 
conditioning/termination 
boards. 
We find that 


we have two types of digital termination 
panels 


available, 
one for low current, 
low voltage 


applications 
and second for higher 
current 
and 


voltage 
uses. If we base our choice on the data 


provided by Figure 8,we will lean toward using the 
iCS 930 panel for our interface. 
This board can 


handle a mixture of signal levels and will support 
up to sixteen individual 
lines, providing 
almost 


double our needs. 


Even a cursory glance at the iSBC 569 controller 
will 
provide 
the 
knowledge 
that 
three 
edge 


connectors 
are utilized to bring the OBS signals 


from the board. 
This 
would indicate 
that 
the 


simplest (and most costly) solution is to use three 
termination 
panels. 
Obviously, we should investi- 
gate further before making such a decision. Three 
possibilities are readily apparent. 
First, we might 


perform some type of re-routing of data lines on 
the board so as to use only one connector. 
Second, 
we can use more than one connector on the ribbon 
cable and perform a parallel 
connection 
of the 


various 
lines 
and 
choose 
them 
so that 
no 


duplication 
of lines results. 
Finally, 
we can use 


some scheme of connecting 
three cables to the 


board and use the optional Port C connectors on 
the termination 
papel. 


The schematic drawings of the IDC indicate that 
only six of the OBS I/O lines of each processor 
socket are broken by wire wrap jumper posts. All 
of the lines so configured are on the Port 2 data 
lines. 
Unless 
we decide 
to cut etch 
and 
add 
30ldered wires, we will not be able to configure our 
board with this technique. 
Some further investi- 
gation is in order before we can make a decision. 
The use of a parallel 
output 
technique 
using 


multiple 
connectors 
on a single cable seems to 


present a feasible approach if we can work out an 
assignment 
of I/O which will not cause conflictb. 


We will begin by building a trial port assignment 
table 
in which 
we will assign 
the 
required 


functions to input/output 
ports. Wewill group the 
inputs and outputs into groups of four to handle 
the terminator/driver 
arrangement 
which is built 
into the board. This table is shown 
in Figure 


11. We obviously have a small problem. We have 


Socket 1 
Socket 2 
Socket 3 
Direction 


Port 
, 


10 
Weight In 
In 
11 
In 
12 
In 
13 
In 
14 
15 
16 
17 
20 
Conv. Mtr. 
Out 
21 
Out 
22 
Out 
23 
Out 
24 
Valve Ph. 1 
Out 
25 
Valve Ph. 2 
Out 
26 
Valve Ph. 3 
Out 
27 
Valve Ph. 4 
Out 


not yet shown the signals from the con veyor speed 
and the liquid flow into the on-board interrupt 
counters. 
The schematics 
show that these signals 


are brought onto the board on the edge connectors 
but the locations correspond to Port C lines which 
do not exist on the iCS 9301 We have available 
input lines on the Port 1 connectors but there is no 
provision to break the signal on the board to route 
it to the counter interrupts. 


If we move on to the third alternative, 
we find that 


the 
interconnection 
paths 
caused 
by tieing 


various 
lines together 
cause even greater 
prob- 


lems. 
Either 
some fact 
must 
have 
been 
over- 


looked, or we must consider the use of more than 


Figure 11 indicates 
that three lines are available 


on the Port 2 data lines which go to jumper posts 
and which could be used if they were not part of an 
output driver of Port 20. If sOIl).etechnique can be 
found to use these "output" 
lines as inputs, 
our 


problem 
will be solved. 
The 
use 
of an 
open 
collector driver can provide us with the ability to 
use the line as an input so long as the drivers are 
turned off! This should be no problem as we can 
force the outputs to this state either through 
the 


appropriate 
jumpering 
of inputs or by outputting 


data to the OBS 1 ports corresponding 
to these 


bits. The resulting electrical configuration 
can be 


seen in Figure 12. 
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Let us examine 
the implications 
of performing 


this interconnection. 
The physical layout of the 


board and the use of the terminator/driver 
sockets 


causes the I/O lines to be grouped into sets of four 
data lines.We must choose which ofthethreeiSBC 
941 modules will be responsible 
for supporting 


each of the lines. In Figure 12,we can see that the 
belt motor is driven by OBS Socket 1, Bit 20. This 
requirement 
has placed output drivers onto data 


Bits 21, 22 and 23. Our requirement is to provide 
two signals 
which can be routed to the counter 


inputs so we must place a terminator 
into either 


socket AID or A16. We have arbitrarily 
chosen to 


use socket AID. The use of the terminators 
in 


parallel with the drivers will not create a problem 
so long as those lines which are used as inputs 


have the driver in the high impedence state. This 
is done by requiring that the output Bits 21 and 22 
of the device 
placed 
into socket 
1 are driven 


low. Finally, we see that the remaining Bit 23 may 
be used as a general 
purpose 
output 
line if it 


becomes required. 


The wiring 
configurations 
for the remaining 
connector groupings 
are shown in Figures 13, 14 
and 
15. In Figure 
13, we see the assignments 
which can be used for Bits 10, 11, 12 and 13. We 
have earlier defined that an iSBC 941 processor 
would be used in a high speed frequency counting 
mode to determine 
the weighbelt 
weight. This 


device will be placed into socket 2. The use ofthis 
mode precludes the use of any general purpose 


r 
10 
I 


SLAVE 
I 
0 
I 


11 
I 
: 


12 
: 
III 
13 


L 


-----, II 
I 
I 
II 
I 
A1 
I 
I 
I 
IIII 
_____ 
.J 
r------, 


P2 
AQ 


~WEIGH8ELT 
/L-.:::-J 
WEIGHT 


"" !"-~-, 
/,,""L 
J SPARE 


~ 


r-~-., 


I SPARE 
L. 
~ 


~ 


•.-A;-, 


I SPARE 
L 
.• 


ICS 930 
TERMINATOR 


input/output 
operations 
of the processor if we 
desire to maintain 
maximum 
accuracy 
of the 
frequency 
measurement. 
We will arbitrarily 


choose 
to use Bit 10 as the location 
of the 


frequency 
count input. 
This will necessitate 
installing a terminator into the socket correspond· 
ing to the processor input. If required, we can 
install open collector drivers into socket A14 and 
use the remaining 
three bits for general purpose 
outputs. If this is done, care must be taken to 
assure that Bit 10ofthe device which is placed into 
socket 3 is placed into a low state as was done in 
the preceding example. 


The interconnection 
scheme for Ports 14 through 
17 can be seen in Figure 14. Note that no ports of 
this group are dedicated to our defined control 


functions. 
These four bits may be used as inputs 
or outputs 
as required by the application. 
For 


example, 
we have ignored the fact that 
actual 


control 
loops incorporate 
solenoids 
for flow 
control routing. The unused bits can be used to 
perform these tasks. 


Figure 
15 shows the interconnections 
for the 


remaining 
group 
of bits. 
There 
are 
several 


features shown on this drawing which should be 
discussed in some detail. Let us first consider the 
remaining 
function 
which we must implement. 


This is the control for the liquid valve stepper 
motor. An iSBC 941 IDP operating in the stepper 
mode will provide the necessary control functions 
to drive the motor. Since all four of this group's 
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data lines are committed to drive the four phases of 
the stepper 
motor, there are no other functions 


available. 


An important 
feature of the iSBC 941 processor is 


illustrated 
in Figure 
12. This is the ability 
to 


enable the processor to generate 
an interrupt 
at 


some point 
in its operation. 
We have 
earlier 


indicated that we will use the processor in socket 2 
(the frequency counter) to provide us with a 200 
msec time reference. When the iSBC 941 proces- 
sor is enabled with an ENFLAG command and is 
operating 
in the frequency 
count mode, it will 


generate 
an interrupt 
on its output 
line, Port 


25. Figure 
15 shows how this interrupt 
can be 


connected to the host board's 
internal 
interrupt 


input structures. 


The hardware 
configuration 
has been defined 


through 
Figure 
14. The actual 
implementation 


can be handled 
through 
the use of the various 


wire-wrap 
jumpers 
on the 
IDC. Drivers 
and 


terminators 
can be installed 
as indicated 
in the 


preceding discussion. 


VI. SOFTWARE CONFIGURATION 


As with most computer controlled systems, 
the 


actual implementation 
of the task is handled with 


software. 
In older designs 
and in many 
mini- 


computer systems, this task has become formid- 
able 
and 
has 
resulted 
in cost over-runs 
and 


schedule delays. Intel provides many tools for use 
by the designer to prevent this type of problem and 
to assist him in easily creating a workable and well 
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documented software configuration. 
Let us look at 
some of these tools in more detail and consider how 
their use will help us to write our programs easily 
and quickly. 


High Level Programming 
Languages 


A valuable tool, which Intel provides the designer 
of small control systems, is the ability to program 
even the smallest 
systems 
using 
a high level 
programming 
language, PL/M-80.' This language 
offers relatively efficient and structured, program- 
ming capabilities. 
It has been determined 
that 
PLIM-80 users can expect to use between 1.1 to 
slightly 
more than 
2 times 
as much program 
memory as would be used for the same task written 
in assembly 
language. 
At the same time, the 
programmer's 
time to code a task will be consider- 
ably less than ifhe were to use assembly language. 


The PL/M-80 
Programming 
Manual 
indicates 
that the language is highly structured 
and lends 
itself very well to handle logical type operations. 
Its weakness in handling 
complex mathematical 
computations 
is compensated 
by the ability 
to 
combine 
the 
user 
application 
software 
with 
packaged Intel support software. 


Fundamental 
Support Packages 


The Intel 8080/8085 Fundamental 
Support Pack- 
age (FSP) 
provides 
a package 
of application 
subroutines 
and functions 
which can be called 
from programs 
written 
in either assembly 
lan- 
guage, PL/M-80, or in FORTRAN-80. It uses a 
standard set of data structures and a unified status 
and error reporting scheme. Nine major groups of 
operations 
are fully supported 
by this package. 
These are: 


1. A primitive fast string handling and integer 
arithmetic 
capability 
without error report- 
ing. 
2. A binary integer arithmetic package which 
performs 
operations 
on both signed 
and 
unsigned 
integers 
of various 
lengths 
in 
binary representation. 
3. The 
floating-point 
arithmetic 
package 
which provides operations on floating point 
numbers in four formats: single precision, 
single-precision extended, double precision, 
and double-precision extended. 


4. The 
decimal 
arithmetic 
routines 
which 
perform integer 
and fixed point computa- 
tions 
on numbers 
which 
are 
stored 
as 
strings of ASCII characters. 
5. A string handling 
section which contains 
routines to transform 
strings and to extract 
and insert substrings. 
A routine for scan- 


ning of general input and one for formatting 
of general output are included. 


6. Routines for number conversion, for numer- 


ic I/O 
transformation 
of data 
from one 
format 
to another, 
input 
scanning 
of 
numeric strings, and formatting of numeric 
strings for output are also available. 


7. The floating point transcendental 
function 
section provides trigonometric, exponential, 
and other transcendental 
functions. 
8. The statistics 
routines 
compute the mean, 


variance, 
and 
standard 
deviation 
of one 
group of statistical 
data, and the covariance 
and correlation factor of two groups of data. 


9. Finally, the PID procedures provide the user 
with a version of the classical Proportional, 
Integral, Derivative control algorithm. 


Clearly, 
the use of the FSP support 
programs 
enhance the logical PL/M-80 program operations. 


Host/Slave 
Relationship 


Before we proceed 
with 
our development, 
we 
should take some time to examine the relationship 
between our iSBC 569 IDe and other controllers 
which 
may 
be installed 
in the 
system. 
The 


utilization of intelligent slave boards provides the 
capability 
to develop 
control 
concepts 
to an 
extremely 
high 
level if certain 
guidelines 
are 
followed. 
We will therefore 
assume 
that 
the 
control solution which we are developing will be 
but a part of an over all control concept which 
utilizes 
multiple 
controllers 
sharing 
common 
resources. 


This concept allows us to develop control algo- 
rithms 
for each sub-process within 
our overall 
control system. 
This development 
can provide 
independent 
design and implementation 
of each 
process. A host processor can be used to provide 
any required inter-process 
communication 
tasks 


and to provide the operator interface. 
We have 


previously 
indicated 
that 
the operator interface 


will provide some means to adjust the weighbelt 


feeder setpoints and the liquid ratio. It should also 
allow the operator to display the current status of 
the process. Since these operator interface func- 
tions are but a part ofthe overall controlfunctions, 
the interface 
should be programmed 
such that 
maximum 
flexibility can be gained through 
its 
use. Fortunately, 
such an interface is available 
using Intel's RMX/80 BASIC-80. 


RMX/80 BASIC-80 Interpreter 


The RMX/80 BASIC-80 Interpreter is a high level 
language interpreter 
with extended disk capabili- 


ties. It operates on iSBC 80 Single Board Compu- 
ters and allows the interpretation 
of BASIC-80 
source code into an internally 
executable form. 
Many 
other 
features 
are available 
and many 


configurations 
are possible depending upon the 
exact system requirements (refer to the BASIC-80 
Reference 
Manual, 
9800758)., 


Maximum 
utilization 
of the operator 
interface 


with a minimum 
of development 
time can be 
achieved with the preconfigured 
version of the 


software/hardware 
package. This will provide us 
with complete disk 110 capabilities and the ability 
to easily program 
and maintain 
any programs 
which may become necessary 
to implement the 
interface. 
The actual 
implementation 
of the 
interface will be done later, after we have defined 
the control task. 


Software Tasks 


The task of preparing the software can be broken 
down into three major groupings or tasks. These 
are defined to be: 


Prepare the Software Drivers. 


This 
involves 
defining. the relationships 


between the control algorithm 
parameters 


and the input/output 
hardware 
devices and 


creating software to implement these defini- 
tions. 


Prepare the Control Algorithm. 
This 
will 
involve 
developing 
a control 


algorithm 
which defines the relationships 
between the various system parameters. This 


algorithm 
will draw heavily 
upon the re- 
sources of the FSP programs 
and the soft- 


ware drivers which relate the parameters 
to 


the physical hardware. 


Finally, the operator interface must be defined 


which will relate the parameters 
used in the 


control scheme to other controllers and to the 
operator. This will allow the control task to 
interact 
in such a manner 
as to provide a 


meaningful 
element of the overall control 


concept. 


VII. SOFfWARE DRIVERS 


Before developing the actual control algorithm, we 
must create the drivers which communicate with 
the three iSBC 941 processors in their assigned 
operating 
modes. 
We will define 
two driver 


sections 
for each processor, one to handle 
the 


initialization, 
and a second to provide the ongoing 


communications 
as required 
by the control 


algorithm program. 


Motor Speed Control Processor 


The first processor which we will discuss is to be 
located in slave socket number 0 and will be used to 
produce 
a variable 
frequency 
output. 
Let us 


consider in some detail how this can be accom- 
plished 
using 
an iSBC 941 Processor. 
First, 


consider the task of initializing 
the device to the 


primary function operating mode, FREQ. 


Referring 
to the 
iSBC 
941 Industrial 
Digital 


Processor 
User's Guide, we find that the initializa- 
tion requires the sequence of commands and data 
shown in Figure 16. We will identify the meaning 
of each of these terms 
and create 
a software 


Description 
Command/Data 


Request INIT 
C 


FREQ Select 
D 
Scale Factor 
D 
Output Enable 
D 
Initial State 
D 


P20 Delay 
D 


P20 Period 
D 


Request PAUSE 
C 


program which will handle the required initializa- 
tion of the processor. The purpose and use of the 
various 
commands 
to the 
processor 
are well 
defined in the user's guide and will not be repeated 
here. 


The 
first 
byte 
of data, 
which 
mhst 
be sent 
following the initialization 
command, is the data 
byte signifying that the operational 
mode is to be 
the 
frequency 
output. 
This 
is defined 
in the 
manual as being equal to the data byte "OB5H" or 
"035H" as expressed in the hexadecimal number- 
ing system. The choice of values 
to be sent is 
dependent upon our desire to utilize the internal or 
external time reference period for the operations. 
If we utilize 
the 
internal 
time reference, 
our 
minimum 
increment 
or resolution 
of operations 
will be 86.72 microseconds. 


To determine 
if this 
speed is adequate 
for our 
frequency generator, we must consider the impact 
that this resolution has on the output. A 550 hertz 
signal 
has 
a period of 1.82 milliseconds. 
If we 


increase this period by the 86.72 microsecond time 
reference, we find that the next increment in the 
frequency generators output will be approximately 
372 hertz. This resolution 
is certainly 
not ade- 
quate to meet the motor control requirements! 
We 
should consider using the external clock to provide 
the 
time 
reference. 
One of the 8253 Interval 
Timers 
on the iSBC 569 board can be used to 


generate a reference time. If we arbitrarily 
choose 
to use a 10 microsecond reference to the IDP, we 
find that the worst case resolution for the 550hertz 
signal becomes about 4 hertz. This is certainly 
within 
our requirements 
of motor control. ThE. 


primary function signal should then be sent as a 
"OB5H". 


The second byte is used to establish a scale factor 
for the processor. This scale factor 
is used to 
generate the basic time increment 
which can be 
used to establish the frequency output; that is, the 
minimum 
time increment 
which can be used to 


establish 
a period or pulse width will be the scale 
factor times the reference time period. 


In our case, because of the wide frequency output 
range, 
we cannot 
specify 
the 
scale 
factor 
at 
initialization 
(later 
data will show the need for 


multiple scale factor ranges). 
We will then only 


need to send some arbitrary value at initialization 
to allow the processor to complete its initialization 
sequence. 


The Output 
Enable 
data 
byte is used to select 
which of the Port 2 output bits are to be used to 
generate 
the 
output 
signals. 
The 
hardware 
configuration established earlier placed the output 
onto Bit 0 of the port, so this data byte shall be 
specified as a byte having only Bit 0set to a logical 
one or equal to 01H. 


The Initial 
Output parameter 
specifies whether 


each bit selected as an output by the output enable 
byte is to be initially set to a logical one or zero 
when 
the processor 
is first 
enabled. 
For this 
application, it really does not matter, but we will 
arbitrarily 
pick the state to be equal to zero. The 
byte will be defined as being set to DOH. 


The 
Delay 
parameter 
is used 
to define 
the 


waveform which will be generated 
and specifies 
the number of time increments which must elapse 
before the waveform will change 
states. 
Rather 


than to constantly 
vary the delay to maintain 
a 


square wave output, we can choose an arbitrary 
value 
of one time increment 
before changing 


state. The output will have a varying duty cycle as 
the frequency 
changes. 
This 
should 
cause 
no 


problems for the translator 
driving the weighbelt 


motor. The byte will be defined as being set to a 
value of 01H. 


Finally, 
the Period 
of the waveform 
must 
be 
chosen. Again, 
this parameter 
will be changed 
according 
to the desired frequency, 
so only an 
arbitrary 
value need be sent. Indeed, since this is 


the last parameter, 
the value could be omitted 
entirely by sending the PAUSE command in its 
place. 


The initial 
data definition 
can be defined using 


PL/M-80 
language 
conventions 
as a block of six 


bytes as shown in Figure 17. 


The actual 
communications 
between 
the host 


processor 
on the iSBC 569 board and the IDP 


utilizes the protocol explained in previous sections 
of this note. The status register of the IDP will be 
tested for the bit signifying that the input buffer 


1* DECLARATION OF iSBC 941 #0 INITIALIZATION 
DATA *I 


DECLARE FREQ 
LITERALLY 'OB5H'; 


DECLARE SF 
LITERALLY 'ooOH'; 


DECLARE OUTPUT$ENABLEOLITERALLY 
'001H'; 


DECLARE INITIAL$STATE 
L1TERALLY'ooOH'; 


DECLARE DELAY 
L1TERALLY '001H'; 


DECLARE PERIOD 
L1TERALLY 'OOOH'; 


1* DECLARATION OF iSBC 941 PRIMARY DATA *I 


DECLARE INIT$0$TABLE(6) 
BYTE DATA ( 
FREQ, 
SF, 
OUTPUT$ENABLEO, 
INITIAL$STATE, 
DELAY, 
PERIOD 
); 


full is not set. This will indicate that the device is 
ready 
to accept 
either 
a command 
or a data 


byte. The command to request a primary function 
will be sent. At this point, the processor will be 
expecting a series of data bytes as specified by the 


function being selected. A "Do Loop" can be used 
to effectively transmit 
this data to the device. The 


program to perform this function is illustrated 
in 


Figure 18. 


1* REQUEST PRIMARY FUNCTION 
*1 


44 
2 
DO WHILE ( (INPUT (UPI$O$STATUS) AND IBF) < > 0); 


45 
3 
END; 
46 
2 
OUTPUT (UPI$O$COMMAND) = INITPF; 


1* LO~D INITIAL PARAMETERS *1 


47 
2 
DO 1=0TO 5; 
48 
3 
DO WHILE ( (INPUT (UPI$O$STATUS) AND IBF) < > 0); 


49 
4 
END; 


50 
3 
OUTPUT (UPI$O$DATA)=INIT$O$TABLE(I); 


51 
3 
END; 


1* TERMINATE PARAMETER LOADING 
*1 


52 
2 
DO WHILE ( (INPUT (UPI$O$STATUS) AND IBF) < > 0); 


53 
3 
END; 


54 
2 
OUTPUT (UPI$O$COMMAND)=PAUSE; 


1* START FREQUENCY FUNCTION 
*I 


55 
2 
DO WHILE ( (INPUT UPI$O$STATUS) AND IBF} < > 0); 


56 
3 
END; 


57 
2 
OUTPUT (UPI$O$COMMAND)=LOOP; 


When all required data parameters 
have been sent, 
the data portion of the initialization 
is terminated 
by sending 
a PAUSE 
command 
as shown 
in 
Figure 18. Note how, in each case before data or a 
command is sent, we wait until the input buffer is 
empty. 
Finally, 
the initialization 
is completed 
when 
we have 
sent 
the LOOP command. 
The 
processor 
will now 
be generating 
an output 
frequency as specified by the parameters. 


Remember 
that, 
according 
to our earlier discus- 
sion and 
as we have 
shown 
in Figure 
12, the 
unused output ports should be set to a logical low 
condition to allow the use ofthose lines as inputs to 
carry 
additional 
data 
into the 
controller. 
This 
should 
be done as a part 
of the initialization 
process. The secondary 
utility command, CLRP2 
is used for this purpose. This process is illustrated 
in Figure 19. 


We should next direct our attention to establishing 
a software 
interface 
which will take the desired 


weighbelt speed term and convert it to a frequency 
output suitable to drive the motor translator. 
We 


know that this will involve selecting a particular 
scale factor and period term which will generate 
the correct waveform. 
Previously, we established 
that, 
for a maximum 
frequency of 550 hertz, we 
need to establish 
a period of 1.82 milliseconds. 


Many combinations 
of Scale Factor 
and Period 
parameter 
will generate this time interval. Ideally, 


the smallest 
increment 
of change 
can be estab- 


lished by setting a constant period and modifying 
the scale factor. If we make some calculations, 
we 


will find that the fact that the scale factor is a byte 
value (giving us a range 
of qetween ° and 255) 


limits the frequency range which can be produced 
using anyone 
value for a period. It seems that we 
will be forced to vary both the period and the scale 
factor as a function of the desired frequency. 


In Figure 20, we have plotted the frequency output 
for various values of Scale Factor and PeriOd. Our 


DO WHILE ( (INP.UT UPI$O$STATUS) 
AND ISF) < > 0); 
END; 
OUTPUT 
(UPI$0$COMMAND)=CLRP2; 


DO WHILE ( (INPUT (UPI$O$STATUS) 
AND ISF) < > 0); 


END 
OUTPUT 
(UPI$O$DATA)=INITIAL$OUTPUT; 


Figure 19. Secondary Utility Command 
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intent 
is to maintain 
the highest 
resolution 
possible for the desired output range of 50 to 550 
hertz. Choosing four period base parameters 
will 
provide us with acceptable waveform generation 
characteristics. 
We will choose the data 
sets of 
Figure 21 based upon the data shown in Figure 20. 


The Period can be determined 
by examining 
the 
desired frequency range. The scale factor can be 
calculated from the equation: 


SF = 10,000 / ( (FREQUENCY) x (PERIOD) ) 


Again, the PL/M-80 language program to imple- 
ment the interface between the host and the IDP is 
easily 
constructed. 
For 
example, 
Figure 
22 
provides 
the· code which 
will be required 
to 
determine the appropriate 
Period parameter 
and 


also illustrates the use ofFSP programs to handle 


the mathematical 
calculations 
required to deter- 


mine the corresponding 
scale factor. 


The principles 
above can be expanded 
into a 


complete interface 
package 
to offload the host 


processor of the need to generate 
the frequency 


waveform 
to the translator 
of the 
weighbelt 


motor. The complete program 
for the processor 
can be found in Appendix A. 


Weight Input Processor 


The second use of an iSBC 941 Processor is to 
provide 
the capability 
of converting 
the high 
frequency inputs 
from the weight sensor of the 


weigh belt into a digital value equivalent 
to the 


actual weight on the belt. This frequency to digital 
conversion can be easily accomplished by the use 
of the Primary Function, FCOUNT. 


Frequency 
Period 
Scale Factor 
Resolution 


50 to 165 Hz. 
9 
221 to 67 
3 Hz. 


166 to 225 Hz 
5 
121 to 89 
3 Hz. 
226 to 285 Hz. 
3 
147 to 117 
3 Hz. 
286 to 550 Hz. 
2 
175 to 91 
6 Hz. 


63 
5 


64 
5 


65 
4 


73 
4 


74 
4 


75 
4 


1* COMPUTATION 
OF FREQUENCY 
RANGE 
*1 


IF FREQ < 285 
THEN DO; 


IF FREQ < 226 
THEN DO; 


IF FREQ < 166 
THEN RANGE = 9; 
ELSE RANGE = 5; 
END; 
ELSE RANGE = 3; 


1* LOAD MATH ACCUMULATOR 
WITH 100,000 *1 


CALL MQULD4 
(.IR,.HUNDRED$K); 


1* TEST FOR MOTOR SHUTDOWN 
*1 


IF FREQ >1 
THEN DO; 


1* DIVIDE BY FREQUENCY 
*1 


CALL MQUDV2 
(.IR,.FREQ); 


1* DIVIDE BY RANGE FACTOR 
*1 


CALL MQUDVl 
(.IR,.RANGE); 


1* GET TWO'S COMPLEMENT 
FOR iSBC 941 SCALE FACTOR 
*1 


CALL MQUSTl 
(.IR,.FREQA); 


FREQA=NOT 
(FREQA + 1); 


END; 


The FCOUNT 
Primary 
Function 
is selected by 
sending the INITPF 
command followed by four 
parameters. 
The process is identical to that which 
was 
used 
in the 
previous 
example 
when 
we 
established 
the FREQ function. 
In this case, the 
sequence is described in the manual as is shown in 
Figure 23. 


Description 
Command/Data 


Request INIT 
C 
Select FCOUNT 
D 
Input Select 
D 
Output Enable 
D 
Sampling Interval 
D 
Request PAUSE 
C 


Let us examine the derivation of the terms which 
must 
make 
up the 
data 
table 
which 
will be 
transmitted 
to the processor in order to initialize 
it. The FCOUNT function does not allow the use 
of an external 
clock so we have no option as to 
which 
command 
will be sent 
to select 
this 
function. 
It is defined to be equal to 33H. This 
becomes the first elemen t of the byte array used to 
contain the initial data. 


The Input Select parameter describes which ofthf. 
Port 1 inputs 
are to be measured. 
If we refer to 
Figure 13,we can see that a hardware assignment 
of Port 10 has been made for this function. 
This 
assignment 
corresponds to bit 0 of the parameter 
being set to a value of 1. The byte value for this 
parameter 
then becomes 01H. 


The Output Enable byte is used to enable an output 
port corresponding with the input to change states 
when the Sampling Interval time has elapsed. Our 
system has a requirement 
to operate the control 
algorithm once each 200 milliseconds and we have 
previously 
indicated 
that 
the frequency counter 
would be used to establish this time interval. 
If the 
output is enabled and connected to an interrupt 
line, it will provide our system with the required 
pacer clock. The output bit from Port 20 will then 
be enabled 
to provide the interrupt. 
The para- 
meter for this byte will be set to the same value as 
the Input Select and becomes 01H. 


The Sampling 
Interval 
will establish 
the time 
interval 
to be used when 
sampling 
the input 
frequency. This time interval should be set to 200 


milliseconds for our application. 
The parameter is 
then calculated from the equation: 


INTERVAL = (SAMPLE PERIOD) / (0.02222) 
OR 
INTERVAL = (0.200) / (0.02222) = 9 


The correct 
sampling 
interval 
for our control 
system should be set to a value of 09H. 


A similar procedure can be used to send this data 
to the processor. The actual code used to imple- 
ment 
the 
system 
can 
be found 
in Appendix 
A. Note that the unused bits of the device have 
been set to a predetermined value as was indicated 
by our hardware 
design of Figure 13. 


Once the processor 
has 
been initiated 
and is 
performing its function, we need only wait until 
the device signals us that the 200 millisecond time 
interval has passed and that it is ready with the 
belt weight. When this interrupt 
occurs, we will 
read the data and perform our controrfunctions. 
An interface 
must 
be established 
between the 
control 
algorithm 
and 
the 
processor 
which 
enables it to receive a value which represents the 
actual weight. 


The 
total 
count 
received 
by the 
processor 
is 
available 
as a sixteen bit count made up of two 
eight bit bytes. The use of the Secondary Utility 
Commands, 
Read 
FCOUNT 
Measurements 
(RDFCO-RDFCF) 
allow 
the 
two bytes 
to be 
transferred 
into the host processor. We are using 
the first counter so we will use the corresportding 
commands, RDFCO and RDFCl. 
An example of 
the procedure to read one of the count bytes can be 
seen in Figure 24. 


The counter can be commanded to begin its next 
sample period by issuing a LOOP command to the 
processor. The two data bytes can be combined to 
form a 16-bit word and the resultant value divided 
by 2 to form a weight value. The division by two to 
obtain weight is required since the count range 
from 0to 2000 corresponds to a weigh t of between 0 
and 10.00 pounds; thus, each count has a value of 
0.005 pounds. The integer numbers 
used in the 
control algorithm are fixed point with an implied 
scale factor of 100. The division by two provides a 
result which meets the criteria. 


/* GET INPUT COUNT 
LOW BYTE *! 
00 WHILE ( (INPUT (UPI$1$STATUS) 
AND IBF) < > 0); 
END; 
OUTPUT 
(UPI$1$COMMANO) 
= ROFCO; 


DO WHILE ( (INPUT$1$STATUS) 
AND OBF) = 0); 
END; 
LCOUNT = INPUT (UPI$1$OA'rA); 


Figure 24. FCOUNT Read Procedure 


Appendix A provides the complete listing of the 
code which 
was 
used 
to interface 
with 
the 
processor 
assigned 
to the primary 
function, 
FCOUNT. 
Stepper 
Motor 
Control 
Processor 


The third 
example 
of utilizing 
the iSBC 941 
Processor in an industrial 
application is provided 
by the processor installed into OBS socket 2. This 
device is used to drive a stepper motor which, in 
turn, controls the liquid valve position. Again, we 
will break the discussion into an initialization 
and 
an interface operational 
mode. 


We find that 
the User's 
Guide indicates 
that 
initialization 
to the STEPPER Primary Function 
is performed 
by sending 
the INIT 
command 
followed 
by up to 21 data 
bytes. 
Figure 
25 
provides 
the table which shows the necessary 
parameters 
for this mode. 


The technique used to place the processor into the 
desired function is the same as we have seen with 
the two other processors so we will not spend time 
dealing 
with the communications 
sequence. In- 
stead, we will examine the techniques which can 
be used to determine the values of the initializa- 
tion parameter 
bytes. 


106 
2 
107 
3 
108 
2 


109 
2 
110 
3 
111 
2 


STEPPER is requested by sending a data byte of 
either 17H or 97H following the INIT command. 
Remember that the significance of setting bit 7 of 
the data high is to request that an external clock 
be used by the processor. There is no reason to use 
an external 
clock for our application, 
so we can 
choose a function request byte of 17H. 


The remainder 
of the data is used to define the 
waveforms 
which 
are 
necessary 
to drive 
the 
stepper motor. We will derive the values for these 
parameters 
by beginning with the manufa~turer's 
data sheet and moving until we have determined 
the correct value for each byte of data. 


The motor chosen for this application utilizes four 
phases to drive the shaft. The data sheet provided 


Description 
Command/Data 


Request INIT 
C 
Select STEPPER 
0 
Select Scale Factor 
0 
Output Enable 
0 
Output 
Polarity 
0 
Common 
Period 
0 
P20TRAN1 
0 
P20TRAN2 
0 
P21TRAN1 
0 
P21TRAN2 
0 
P22TRAN1 
0 
P22TRAN2 
0 
P23TRAN1 
0 
P23TRAN2 
0 
P24TRAN1 
0 
P24TRAN2 
0 
P25TRAN1 
0 
P25TRAN2 
0 
P26TRAN1 
0 
P26TRAN2 
0 
P27TRAN1 
0 
P27TRAN2 
0 
Request PAUSE 
C 


information 
for both a Four-Step Input Sequence 
(1.8 degrees per step) and for an Eight-Step Input 
Sequence (0.9 degrees per step). Wewill use the 1.8 
degree step angles for our example and applica- 
tion. The data provided by the manufacturer 
is 
shown in Figure 26. The first task is to convert the 
switch state diagram into a desired waveform for 
each of the four phases. 
This has been done in 
Figure 27. 


Beginning with Scale Factor, let us determine the 
required 
data 
parameters 
which 
will yield 
a 
stepper controller compatible with our motor. The 
Scale Factor 
will provide 
the minimum 
time 
period for one step to take place. The minimum 
time which we can specify is a function of both the 
motor characteristics 
and 
of the TRP for the 
primary function, STEPPER. 
The minimum TRP 
is determined by referencing the IDP User's Guide 
for the desired function. 
In this case, it is found to 
be 325 + (13 x B) where B is the number of phases 


STEP 
SW1 
SW2 
SW3 
'SW4 


1 
ON 
OFF 
ON 
OFF 
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ON 
OFF 
OFF 
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3' 
OFF 
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ON 
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which are used. The result will be expressed in 
terms of processor cycles and can be converted 
into time by multiplying by 2.71 microseconds per 
cycle. This works out to be: 


325 + (13 x 4) = 377 PROCESSOR 
CYCLES 
OR 


377 x 2.71 = 1.021 MILLISECONDS 


Now, let's examine the minimum time which can 
be utilized by the stepper motor. This is given in 
the manufactuer's 
data sheets as being 2.86 milli- 


seconds for the motor which we have chosen to 


use. This value must be used to compute the Scale 
Factor 
for this application. 
The Scale Factor is 


computed by dividing the minimum step time by 
86.72 microseconds or: 


SF=2,86 MILLISECONDS/86.72 
MICROSECONDS=33 


This number is entered into the processor using 
two's complement which becomes equal to ODFH. 


The Output Enable is used to specify which of the 
eight possible control outputs 
are to be used to 
control 
the motor 
phases. 
The motor 
phase 
assignments 
to I/O ports was made in Figure 15 
and indicates 
that 
Ports 24 through 
27 will be 


enabled 
for the primary 
function. 
Setting 
the 
corresponding bits provides a parameter to be sent 
to the processor of OFOH. 


The rest of the parameters 
deal with providing a 


definition ofthe waveforms generated in Figure 26 
to the processor. The following paragraphs 
deal 


with 
the 
operations 
required 
to convert 
the 


graphic representation 
into data parameters. 


Each phase must be initialized to an initial output 
state which corresponds to the signal level shown 
for Step 0 of Figure 27. A "I" will be placed into 
the bit corresponding 
to each of the port's output 


bits which are to be in a logical one state upon 


reaching step O. We see that Bits 24 and 26 are set 
corresponding 
to phase 1 and 3. The data byte for 
Initial Output is thus defined to be 050H. 


The Period parameter for a stepper motor function 
corresponds 
to the number 
of steps which are 
defined in the motor's step sequence. Our example 
uses a four step sequence so the Common Period 
will be set to a value of 04H. 


The remainder 
of the initialization 
parameters 
define the transitions 
of each of the phases. 
This 
involves the examination 
of the waveform and 
noting 
the 
points 
at which 
the 
output 
level 
changes. 
This 
data 
can be input 
to allow the 
device to accurately 
produce the control wave- 
forms for any stepper motor control mode. We are 
not using the first four output bits so the transition 
definitions 
for these outputs is meaningless 
and 
will be output as zeroes. The waveform for output 
Port 24 shows a transition 
at steps 1 and 3. The 
parameter 
for the first 
transition 
of Port 
24, 
P24TRANI 
is defined to be OOH.Likewise, the 
second transition, 
P24TRAN2 is set to a value of 
02H. 


The technique 
used above can be continued 
to 
define the constants, 
P25TRANI and P25TRAN2 
as being the same as for Port 24 or OOHand 02H 
respectively. 


The transitions 
for the phases driven from Port 26 
and 27 can be seen to occur at steps 1 and 3 so the 
data for those parameters 
can easily be seen to be 
set to OIH and 03H for each port. 


The 
initialization 
table 
can 
be sent 
to the 
processor using the same techniques as were used 


for the processors 
discussed 
previously. 
The 
complete program 
for the initialization 
can be 
found in Appendix A. 


A driver must next be prepared which will be used 
to provide 
the interface 
between 
the control 
algorithm and the IDP processor which supports 
the stepper motor. When the STEPPER 
primary 
function is used, a queue is utilized for supporting 
the step commands to the motor. Each command 
. to the stepper consists of a data byte signifying the 
step rate to be used and a data byte which provides 
the signed magnitude of the number of steps to be 
moved. Using the motor to control a flow control 
valve allows us to use a constant 
step rate, but 
some type of program must be prepared which will 
convert the signed two's complement representa- 
tion ofthe position from the control algorithm to a 
signed magnitude 
format. 


The number 
conversion 
is easily done and the 
PL/M -80programming 
code to perform the format 
change is shown in Figure 28. 


The data 
queue 
allows 
up to six movement 
commands 
to be present 
and 
waiting 
to be 
serviced by the IDP. If the processor is behind in 
its operations 
and,cannot 
accept 
a seventh 
request, 
the host 
must 
wait 
until 
one of the 
requests 
in the queue has 
been serviced. 
The 
queue status bits can be tested to determine if room 
exists for another command and the "queue not 
empty" 
bit 
can 
be tested 
to verify 
that 
all 
requested 
movements 
have 
been completed. 
Normal operation of our motor should be such that 
the queue is not allowed to fill to its maximum 
capacity. 


1* SUPPORT CONVERSION TO SIGNED MAGNITUDE NUMBER *1 
IF POSITION> 
127 
THEN DO; 


1* GET MAGNITUDE OF MOVEMENT *1 


POSITION = 256 - POSITION; 


1* SET SIGN FOR CCW ROTATION *1 


POSITION = POSITION OR REVERSE; 


END; 


The code which is required to test the queue and to 
send a stepper 
movement 
request 
is shown 
in 


Figure 
29. The complete 
code can be seen in 


Appendix A. 


VIII. 
APPLICATION 
SOFrWARE 


Having developed the software which is required 
to support the Industrial 
Digital Processors, 
we 
can now devote our time to the task of implement- 
ing the application 
software and of handling 
any 
programs which are required to support functions 
unique to the host iSBC 569 board. This software 
can 
be grouped 
into 
two general 
categories, 
initialization 
programs, 
and 
control 
algorithm 


programs. 


Initialization 
Programs 


The initialization 
ofthe iSBC 569 involves setting 
up the required configuration 
of interrupt 
hand- 


ling and of the devices which are installed into the 
slave sockets. For the purposes of this applica- 
tion, 
we will include 
some system 
diagnostic 
capabilities 
within 
the process. These routines 
will be executed each time a RESET or a POWER- 
UP occurs. Only the highlights 
of the code used 


will be presented in detail; however, the complete 
listings 
of the initialization 
programs 
can be 


found in Appendix A by referring to the BCKGND 
Program listing. 


A unique feature of using the iSBC 941 processors 
is their 
ability 
to provide, 
upon 
request, 
an 


identification 
code. The initiation 
diagnostic 


program takes advantage 
of this fact by interro- 


gating 
each processor 
and verifying 
that 
the 
correct ID code is returned. 
If any of the proces- 


sors have failed catastrophically 
or if the internal 


data bus ofthe host board has failed, the program 
will provide an indication 
of this fact. 


Each of the slave processors has, associated with 
it, an individual 
hardware 
reset line which 
is 


under the control of the host. A reset or power up 
condition will cause the control lines to reset to the 
state which hold each slave in a reset state. 
Before 


any slave can be used, it's associated 
reset line 


must be de-activated. 
This is done by sending a 


logical one to the corresponding 
bit of the Reset 


Latch. 
Other bits of the Reset Latch can be used to 


illuminate 
the on-board LED or to generate 
an 


interrupt 
to another 
board on the Multibus data 


bus. 


A special PL/M-80 command is utilized to disable 
the reset interrupts 
of the 8085A host processor. 


Execution of this command will allow all servic- 
able interrupts 
to enter via the 8259A Interrupt 
Controller. 
The command which will mask offthe 


unused interrupt 
structure is shown in Figure 30. 


The initialization 
process must also initialize the 


FSP Integer Record. This will allow the use of the 
math support routines 
which will be required to 


support the control algorithm. 


1* VERIFY THAT QUEUE SPACE IS AVAILABLE 
*1 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND QF) < > 0); 


END; 


148 
3 
149 
4 


150 
3 


1* REQUEST DESIRED STEP RATE *1 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND IBF) < > 0); 


END- 
OUT'PUT (UPI$2$DATA) 
= STEP$RATE; 


151 
3 
152 
4 
153 
3 


1* REQUEST STEPPER MOVEMENT 
*I 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND IBF) < > 0); 


END- 
OUT'PUT (UPI$DATA) = POSITION; 


Control Algorithm 
Programs 


The program which actually handles the control 
algorithm 
for the two loops can be found 
in 
Appendix A, MAIN$CONTROL. 
The flow of the 
program 
is straightforward 
and can easily 
be 
followed by reading 
the listing. 
The operations 


are primarily handled by the use of repeated calls 
to the FSP integer 
math 
routines 
and to the 
processor 
interface 
modules 
which 
we have 
previously generated. 


It is beyond the scope of this application 
note to 
dwell upon the techniques 
which were used to 
generate the PID control routine; this aspect will 
be covered in a future application 
note. 


Limits were placed upon the control outputs so 
that the signals to the processors would not exceed 
the physical 
limits of the external 
devices. For 
example, the frequency range is limited to range 
between 
0 and 
550 to correspond 
with 
the 


operating 
range 
of the weigh belt as we have 
defined it. The limits upon the liquid control valve 
have been set at plus and minus 10steps since this 
is the maximum distance which the stepper motor 
can travel in anyone 200 millisecond time period; 
increasing the possible count could result in filling 
the queue. This could cause the 200 millisecond 
time to be extended if we had to wait for the queue 
to empty. 


Master Processor 


A complete control solution to the weigh belt feeder 
and the liquid applicator has now been developed. 
The process is stand 
alone and resides entirely 


upon 
a single 
board. 
It can operate 
without 


requiring 
any access from the MULTIBUS bus, 


thus freeing the bus for other control, monitoring 
or supervisory duties. 


The system developed for this application 
note 


requires a setpoint for the mass flow and a liquid 
ratio 
be provided 
to the control 
system. 
This 


information 
would normally be supplied by some 


type of bus master device. We have chosen to use 
the pre-configured RMX/SO BASIC-SOInterpreter 
to perform this task. A simple program needs to 
be prepared which will allow adjustment 
of the 


setpoints 
and monitoring 
of the operation of the 


control system. 


Using BASIC will provide full disk I/O capabil- 
ities to the operator. Communicating 
with the 


system through a CRT terminal, he can write and 
execute programs 
which use the resources of the 
system disk or of any ofthe controllers which may 
be present on the bus. 


Two programs 
are required 
to perform 
this 
task. Since they are written in BASIC, they may 
easily be modified or expanded if the need should 
ever arise. 
Indeed, 
other 
programs 
could be 
written to perform other tasks, such as optimizing 
the control parameters. 


In both programs, the parameters 
involved with 
the control operation 
are accessed by using the 
PEEK and POKE instructions. 
Remember that 
the iSBC 
569 controller 
allows 
the 
on-board 
memory to be made available to other devices on 
the bus through the dual port mechanism. 
In our 
application, 
this has been done by jumpering the 
board such that the on-board memory beginning 
at location SOOOHcan be accessed on the bus at 
location 2000H. This mapping was done since the 
memory locations at 2000H are not used by BASIC 
unless requested to do so. A byte of data which is 
at location S27EH on the controller can be read by 
performing 
a PEEK of location 227EH. Some of 
the memory assignments 
for the controller have 
been shown in Figure 31. 


829 F H 
8233 
H 
825 F H 
OODCH 
OOE6H 
827 AH 
OOE8H 
8280 
H 
8285 
H 
8288H 
OOEFH 
01ADH 
81 F 7H 
825DH 
8268H 
OOE4H 
8277 
H 
827CH 
OOE9H 
8282 
H 
8287 
H 
828 AH 
3F 0 OH 
8209H 
825 EH 
00D4H 
ODE 5H 
8278 
H 
827 EH 
OOEAH 
8284H 
OOEBH 
OOEDH 
OOF 1 H 


SYM 
MEMOAY 
SYM 
PALO 
SYM 
CONSTANT$1 
SYM 
BOUNDS2 


SYM 
TlMEINTEAVAL 


SYM 
1I0UIDFLOW 
SYM 
DISTAEV 
SYM 
MASSFLOW 


SYM 
1I0UIDVALVE 
SYM 
DUMMY 
SYM 
ZEAO 
SYM 
PIDAUN 


SYM 
IA 
SYM 
1I0COUNT 
SYM 
CONSTANTS2 


SYM 
CONTAOL1 


SYM 
BELTSPEED 
SYM 
MASSSETPOINT 
SYM 
CONVLENGTH 
SYM 
BELTCONTAOL 
SYM 
SYSTEMAUNNING 
SYM 
ICW 
SYM 
JUMPTABLE 
SYM 
PACV 
SYM 
BELTCOUNT 
SYM 
BOUNDS1 


SYM 
CONTAOL2 


SYM 
BELTWEIGHT 
SYM 
SETPOINT 
SYM 
SIX 
SYM 
1I0UIDAATIO 
SYM 
EAAOAFI ELD 
SYM 
THOUSAND 
SYM 
INITIATION 


The first program 
involves 
setting 
up the two 


control parameters 
and handling 
the control flag 


which causes the process to start and to stop. This 
program 
can be found in Figure 32. 


10 REM THIS PROGRAM IS USED TO INPUT SETPOINTS 
15 REM TO THE LIQUID CONTROL SYSTEM. 
20 POKE 02287H,0 
25 INPUT "ENTER MASS SETPOINT-";MS 
26 IF MS > 1200 THEN 25 
30 MS=CINT(MSx10/60) 
35 H=INT(MS/256) 
40 L=CINT(MS-Hx256) 
45 POKE 0227EH,L 
50 POKE 0227FH,H 
55 INPUT "PERCENT L1QUID-";LR 
60 LR=CINT(LR) 
65 IF LR > 127 THEN 55 
70 POKE 02284H,LR 
75 POKE 02287H,1 
80 RUN "STATUS" 


Upon completion of the initialization 
program, 
a 


8econd program provides a di8play of the system 
operation. 
This 
program 
could 
have 
been 
an 


optional 
program 
which is only called when the 


operator desires to view the system operation. 
A 


program which provides a snapshot 
of the system 


operation 
is shown 
in Figure 
33. Again, 
the 


program is interactive 
with the operator and can 


easily 
be modified 
at any 
time to reformat 
or 


display additional 
information. 


IX. CONCLUSION 


The purpose of this application 
note has been to 


demonstrate 
some of the techniques which can be 


used to provide a control system design solution 
using an intelligent 
slave concept. This has been 


done and the system has been constructed and has 
been found to operate as the design specified. The 
Intelligent 
Slave Concept does provide a single 


board solution to distributed 
control and certainly 


off-loads the master 
processor 
of control duties. 


PROGRAM NAME: STATUS 


10 I=PEEK(0227EH) 
20 H=PEEK(0227FH) 
30 MS=((256xH)+L)x60/10 
40 L=PEEK(02278H) 
50 H=PEEK(02279H) 
60 WT=((256xH)+L)/100 
70 L=PEEK(022890H) 
80 H=PEEK(02281H) 
90 AM=((256xH)+L)x60/10 
100 MT=PEEK(02294H) 
110 LR=(PEEK(02284H))/100 
120 LS=AMxLR 
130 L=PEEK(0227AH) 
140 H=PEEK(0227BH) 
150 LF=((256xH)+L)/100 
160 PRINT "MASS SETPOINT","WEIGHT","ACTUAL 
MASS","MOTION" 
170 PRINT MS,WT,AM,MT 
180 PRINT "LIQUID RATIO","L1QUID SET","L1QUID FLOW" 
190 PRINT LR,LS,LF 
200 Z=PEEK(02285H) 
210 IF Z < 128 THEN 230 
220 Z=256-Z 
225 Z=O-Z 
230 L=PEEK(02282H) 
231 H=PEEK(02283H) 
232 BS=((256xH)+L)x60/200 
239 PRINT "STEPPER";Z, "BEL T";BS 
240 PRINT"" 
250 PRINT"" 
260 FOR N=O to 1000 
270 NEXT N 
280 GO TO 10 


This 
frees the master 
to provide 
supervisory 
control and human interface duties. 


Certainly, 
this 
concept 
can be expanded 
to 
encompass 
a broad variety 
of complex control 


situations. 
At the same time, there is no reason 


why the Intelligent Slave board could not be used 
to provide a single board solution to a simple 
control 
application 
where no interaction 
with 
other processes is required. 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
BACKGROUNDMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:F1:BCKGND.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:F1:BCKGND.PLM 
DEBUG 
PAGEWIDTH(72) 
TITLE('BA 
-CKGROUND 
PROGRAM') 


/****************************************** 
* 
THIS 
IS 
THE 
MAIN 
BACKGROUND 
OPERATING 
* 
* 
PROGRAM 
FOR 
THE 
PID 
CONTROL 
SYSTEM. 
* 
******************************************/ 


/* DECLARATION 
OF 
BOARD 
I/O 
DECLARE 
UPI$0$STATUS 
DECLARE 
UPI$l$STATUS 
DECLARE 
UPI$2$STATUS 


'0E5H'; 
'0E7H'; 
'0E9H' ; 


ASSIGNMENTS 
*/ 


LITERALLY 
LITERALLY 
LITERALLY 


DECLARE 
UPI$0$COMMAND 
DECLARE 
UPI$l$COMMAND 
DECLARE 
UPI$2$COMMAND 


LITERALLY 
'0E5H'; 


LITERALLY 
'0E7H~; 


LITERALLY 
'0E9H'; 


DECLARE 
UPI$0$DATA 
DECLARE 
UPI$l$DATA 
DECLARE 
UPI$2$DATA 


LITERALLY 
'0E4H'; 


LITERALLY 
'0E6H'; 


LITERALLY 
'flE8H'; 


/* DECLARATION 
OF 
RAM 
TEST 
DECLARE 
BEGIN$RAM 
DECLARE 
END$RAM 
DECLARE 
ZERO$PATTERN 
DECLARE 
ONES$PATTERN 


'8000H'; 
'8500H' ; 
'000H' ; 
'0FFH'; 


PARAMETERS 
*/ 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 


/* DECLARATION 
OF 
RESET 
DECLARE 
RESET$UPI$0 
DECLARE 
RESET$UPI$l 
DECLARE 
RESET$UPI$2 
DECLARE 
LIGHT$LED 
DECLARE 
MULTI$INTR 


LATCH 
BIT 
ASSIGNMENTS 
*/ 


LITERALLY 
'00000001B'; 


LITERALLY 
'00000010B'; 


LITERALLY 
'00000100B'; 


LITERALLY 
'00001000B'; 


LITERALLY 
'00010000B'; 


/* 
DECLARATION 
OF 
ISBC 
941 
STATUS 
BITS 
*/ 
DECLARE 
IBF 
LITERALLY 
'00000010B'; 


DECLARE 
OBF 
LITERALLY 
'00000001B'; 


/* DECLARATION 
OF 
ISBC 
941 
COMMANDS 
*/ 
DECLARE 
IDEN 
LITERALLY 
'000H'; 


/* DECLARATION 
OF 
ISBC 
941 
IDENTIFICATION 
CODE 
*/ 


DECLARE 
SBC941 
LITERALLY 
'41H'; 


/* 
DECLARATION 
OF 
MEMORY 
TEST 
ADDRESS 
REGISTER 
*/ 


DECLARE 
I 
ADDRESS 
AT 
(87FEH); 
DECLARE 
MEMLOC 
BASED 
I 
BYTE; 


/* DECLARATION 
OF PL/M-80 
SIM INSTRUCTION 
*/ 
S$MASK: 
PROCEDURE 
(MASK) EXTERNAL; 
DECLARE 
MASK 
BYTE; 
END S$MASK; 


/* DECLARATION 
OF INITIATION 
TASK 
*/ 
INITIATION: 
PROCEDURE 
EXTERNAL; 
END INITIATION; 


/* CLEAR 
ISBC 941 DEVICES 
USING 
ON-BOARD 
RESET 
*/ 
OUTPUT 
(RESET$LATCH$ADR) 
= 0; 


/* MASK OUT THE RESET 
INTERRUPTS 
OF THE PROCESSOR 
*/ 


CALL 
S$MASK 
(MASKS); 


/* TEST MEMORY 
RAM LOCATIONS 
*/ 
DO I = BEGIN$RAM 
TO END$RAM; 
MEMLOC 
= ZERO$PATTERN; 
DO WHILE 
MEMLOC 
<> 
ZERO$PATTERN; 
END; 


MEMLOC 
= ONES$PATTERN; 
DO WHILE 
MEMLOC 
<> 
ONES$PATTERN; 
END; 
END; 


/* RELEASE 
941 LOCKOUT/RESET 
OUTPUT 
(RESET$LATCH$ADR) 
BITS 
*/ 


RESET$UPI$0 
OR 
RESET$UPI$1 
OR 
RESET$UPI$2 
OR 
MULTI$INTR; 


/* VERIFY 
THAT 
SBC941 
PROCESSOR 
IS IN SOCKET 
0 */ 


DO WHILE 
«(INPUT 
(UPI$0$STATUS) 
AND 
IEF) <> 
0); 
END; 
OUTPUT 
(UPI$0$COMMAND) 
= IDEN; 
DO WHILE 
«INPUT 
(UPI$0$STATUS) 
AND 
OBF) 
0); 
END; 
DO WHILE 
(INPUT 
(UPI$0$DATA) 
<> SBC941); 
END; 


/* VERIFY 
THAT SBC941 
PROCESSOR 
IS IN SOCKET 
1 */ 
DO WHILE 
(INPUT 
(UPI$1$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT 
(UPI$1$COMMAND) 
= IDEN; 
DO WHILE 
«INPUT 
(UPI$1$STATUS) 
AND 
OBF) 
0); 


END; 
DO WHILE 
(INPUT 
(UPI$1$DATA) 
<> 
SBC941); 
END; 


/* VERIFY 
THAT SBC941 
PROCESSOR 
IS IN SOCKET 
2 */ 


DO WHILE 
((IN~UT 
(UPI$2$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT 
(UPI$2$COMMAND) 
= IDEN; 
DO WHILE 
((INPUT 
(UPI$2$STATUS) 
AND 
OBF) 
0); 


END; 
DO WHILE 
(INPUT 
(UPI$2$DATA; 
<> SBC941); 
END; 


1* START-UP 
TEST 
OK- TURN 
OFF LED */ 


OUTPUT 
(RESET$LATCH$ADR) 
= RESET$UPI$0 
OR 


RESET$UPI$1 
OR 


RESET$UPI$2 
OR 


LIGHT$LED 
OR 


MULTI$INTR; 


/* INITIATE 
THE CONTROL 
DEVICES 
*/ 


CALL 
INITIATION; 


/* PERFORM 
BACKGROUND 
TASKS .*/ 


DO WHILE 
1; 
HALT; 
END; 


CODE AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


128 LINES READ 
o PROGRAM 
ERROR(S) 


00D4H 
0000H 
0002H 


212D 


0D 
2D 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
MAINCONTROLMODULE 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:CNTTSK.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:CNTTSK.PLM 
DEBUG 


$INTVECTOR(4,3F00H) 
$PAGEWIDTH (72) 
$TITLE('MAIN 
CONTROL') 


/**************************************************** 
* 
MAIN$CONTROL$TASK 
* 
* THIS 
TASK 
IS USED TO CONTROL 
THE TWO 
PID CONTROL 
* 
* LOOPS. 
ONE LOOP CONTROLS 
THE SPEED 
OF A CONVEYOR 
* 
* WHILE 
THE SECOND 
CONTROLS 
THE FLOW OF A LIQUID. 
* 
* THE TASK 
OPERATES 
EACH 
200 MSEC. 
* 
* 
* 
******** 
VERSION 
1.1 *******************************/ 


/* DECLARATION 
OF PID RECORD 
SET-UP 
TASK */ 
UQPSET: 
PROCEDURE 
(PR$PTR,ERROR$FLD$PTR,PRIV$PTR) 
EXTERNAL 


DECLARE 
(PR$PTR,ERROR$FLD$PTR,PRIV$PTR) 
ADDRESS; 


END UQPSET; 


/* DECLARATION 
OF PID CONTROL 
BITS */ 
UQPSCT: 
PROCEDURE 
(PR$PTR,CONTROL$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,CONTROL$PTR) 
ADDRESS; 
END UQPSCT; 


/* PROCEDURE 
TO SET UP PID CONSTANTS 
*/ 
UQPSCN: 
PROCEDURE 
(PR$PTR,CONSTANT$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,CONSTANT$PTR) 
ADDRESS; 
END UQPSCN; 


/* DEFINE 
THE DEFAULT 
ERROR 
HANDLER 
*/ 


UQPSBD: 
PROCEDURE 
(PR$PTR,BOUND$PTR) 
EXTERNAL; 


DECLARE 
(PR$PTR,BOUND$PTR) 
ADDRESS; 
END UQPSBD; 


/* PROCEDURE 
TO CHANGE 
THE TIME 
INTERVAL 
*/ 
UQPSTI: 
PROCEDURE 
(PR$PTR,TIME$INTERVAL$PTR) 
EXTERNAL; 


DECLARE 
(PR$PTR,TIME$INTERVAL$PTR) 
ADDRESS; 
END UQPSTI; 


/* DECLARATION 
OF THE PID CONTROL 
PROGRAM 
*/ 
UQPPID: 
PROCEDURE 
(PR$PTR,IR$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,IR$PTR) 
ADDRESS; 
END UQPPID; 


/* DECLARATION 
OF WEIGHBELT 
SPEED 
INTERFACE 
*/ 
WEIGHBELT$SPEED: 
PROCEDURE 
BYTE 
EXTERNAL; 
END WEIGHBELT$SPEED; 


/* DECLARATION 
OF WEIGHBELT 
WEIGHT 
INTERFACE 
*/ 
WEIGHBELT$WEIGHT: 
PROCEDURE 
ADDRESS 
EXTERNAL; 
END WEIGHBELT$WEIGHT; 


/* DECLARATION 
OF LIQUID 
FLOW RATE 
INTERFACE 
*/ 
LIQUID$FLOW$RATE: 
PROCEDURE 
ADDRESS 
EXTERNAL; 
END LIQUID$FLOW$RATE; 


/* DECLARATION 
OF WEIGHBELT 
MOTOR 
DRIVE 
INTERFACE 
*/ 


WEIGHBELT$MOTOR$DRIVE: 
PROCEDURE 
(SPEED) EXTERNAL; 
DECLARE 
SPEED ADDRESS; 
END WEIGHBELT$MOTOR$DRIVE; 


/* DECLARATION 
OF LIQUID 
VALVE 
INTERFACE 
*/ 
L~QUID$VALVE$POSITION: 


.PROCEDURE 
(POSITION) EXTERNAL; 
DECLARE 
POSITION 
BYTE; 
END LIQUID$VALVE$POSITION; 


/* DECLARATION 
OF PROCESSOR 
0 INITIALIZATION 
MODULE 
*/ 
PROCESSOR$0$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END PROCESSOR$0$INITIALIZATION; 


/* DECLARATION 
OF PROCESSOR 
1 INITIALIZATION 
MODULE 
*/ 
PROCESSOR$l$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END PROCESSOR$l$INITIALIZATION; 


/* DECLARATION 
OF PROCESSOR 
2 INITIALIZATION 
MODULE 
*/ 
PROCESSOR$2$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END PROCESSOR$2$INITIALIZATION; 


/* DECLARATION 
OF PIT COUNTER 
1 INITIALIZATION 
*/ 


COUNTER$l$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END COUNTER$l$INITIALIZATION; 


/* DECLARATION 
OF PIT COUNTER 
2 INITIALIZATION 
*/ 


COUNTER$2$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END COUNTER$2$INITI~LIZATION; 


/* DECLARATION 
OF FSP UNSIGNED 
LOAD PROCEDURES 
*/ 
42 
1 
MQULD1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
43 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


44 
2 
END MQULD1; 


45 
1 
MQULD2 : PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


46 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


47 
2 
END MQULD2; 


/* DECLARATION 
OF FSP UNSIGNED 
MULTIPLY 
PROCEDURE 
*/ 
48 
1 
MQUML1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
49 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


50 
2 
END MQUML1; 


51 
1 
MQUML2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
52 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


53 
2 
END MQUML2; 


/* DECLARATION 
OF FSP UNSIGNED 
DIVIDE 
PROCEDURE 
*/ 
54 
1 
MQUDV1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
55 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
56 
2 
END MQUDV1; 


57 
1 
MQUDV2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
58 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


59 
2 
END MQUDV2; 


/* DECLARATION 
OF FSP SIGNED 
DIVIDE 
PROCEDURE 
*/ 
60 
1 
MQSDV1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
61 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


62 
2 
END MQSDV1; 


63 
1 
MQSDV2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
64 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


65 
2 
END MQSDV2; 


/* DECLARTATION 
OF FSP SIGNED 
STORE 
PROCEDURE 
*/ 
66 
1 
MQSST2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
67 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
68 
2 
END MQSST2; 


/* DECLARATION 
OF FSP SIGNED 
LOAD PROCEDURE 
*/ 
69 
1 
MQSLD2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
70 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


71 
2 
END MQSLD2; 


/* DECLARATION 
OF FSP SIGNED 
SUBTRACT 
PROCEDURE 
*/ 
72 
1 
MQSSB2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
73 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


74. 
2 
END MQSSB2; 


/* DECLARATION 
OF FSP UNSIGNED 
STORE 
PROCEDURE 
*/ 
75 
1 
MQUST1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
76 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


77 
2 
END MQUST1; 


78 
1 
MQUST2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
79 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


80 
2 
END MQUST2;, 


11010 
1101 
1102 


1104 
1105 


/* DECLARATION 
OF 
FSP 
SIGNED 
MULTIPLY 
PROCEDURE 
*/ 


MQSMLl: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END 
MQSMLl; 


$EJECT 
/****************************************** 
* 
DATA 
STORAGE 
AREAS 
FOR 
THE 
PID 
CONTROL 
* 


******************************************/ 


/* DEFINITION 
OF 
LIMITATION 
DECLARE 
MAX$MOTOR$SPEED 
DECLARE 
MIN$MOTOR$SPEED 
DECLARE 
MAX$VALVE$MOVEMENT 
DECLARE 
MIN$VALVE$MOVEMENT 


CONSTANTS 
*/ 


LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 


'55e' ; 
'10 ' ; 
, 110 ' ; 
'-10' ; 


/* DEFINITION 
OF 
PID 
PARAMETER 
DECLARE 
FEEDER$CIO 


DECLARE 
FEEDER$Cl 
DECLARE 
FEEDER$C2 
DECLARE 
FEEDER$C3 
DECLARE 
FEEDER$TIME$INTERVAL 
DECLARE 
FEEDER$SCALE$FACTOR 


COEFFICIENTS 
*/ 


LITERALLY 
'I'; 


LITERALLY 
'I'; 


LITERALLY 
'1'; 


LITERALLY 
'1'; 


LITERALLY 
'1'; 


LITERALLY 
'1'; 


LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 


,I' ; 
,1' ; 
, 1' ; 
,l' ; 
, 1' ; 
,110 ' ; 


DECLARE 
LIQUID$CIO 


DECLARE 
LIQUID$Cl 
DECLARE 
LIQUID$C2 
DECLARE 
LIQUID$C3 
. 


DECLARE 
LIQUID$TIME$INTERVAL 
DECLARE 
LIQUID$SCALE$FACTOR 


PARAMETERS 
*/ 


LITERALLY 
'0EAH'; 


LITERALLY 
'07H'; 


LITERALLY 
'IOFH'; 


/* 
RESERVE 
18 
BYTES 
FOR 
THE 
INTEGER 
RECORD 
*/ 


DECLARE 
IR 
(18) 
BYTE 
PUBLIC; 


/* RESERVE 
42 
BYTES 
FOR 
EACH 
PID 
RECORD 
*/ 


DECLARE 
PRCV 
(42) 
BYTE; 
DECLARE 
PRLQ 
(42) 
BYTE; 


/* 
RESERVE 
SPACE 
FOR 
COUNTER 
DATA 
*/ 


DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE 
PUBLIC; 


/* 
RESERVE 
DECLARE 
Cel 
Cl 
C2 
C3 
DT 
S 


12 
BYTES 
FOR 
EACH 
CONSTANT 
CONSTANTSI 
STRUCTURE 
( 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS 
); 


/* DEFINITION 
OF 
RESET 
LATCH 
DECLARE 
RESET$LATCH$ADR 
DECLARE 
INDICATOR$ON 
DECLARE 
INDICATOR$OFF 


III 
112 


DECLARE 
CONSTANTS2 
STRUCTURE 
( 
C0 
ADDRESS, 
Cl 
ADDRESS, 
C2 
ADDRESS, 
C3 
ADDRESS, 
DT 
ADDRESS, 
S 
ADDRESS); 
/* RESERVE 
8 BYTES 
FOR EACH BOUNDS 
ARRAY 
*/ 
DECLARE 
BOUNDSI 
(4) ADDRESS 
DATA 
( 
000H, 
000H, 
MAX$MOTOR$SPEED, 
MIN$MOTOR$SPEED 
); 
DECLARE 
BOUNDS2 
(4) ADDRESS 
DATA 
( 
000D, 
000D, 
MAX$VALVE$MOVEMENT, 
MIN$VALVE$MOVEMENT 
); 


/* RESERVE 
1 BYTE 
FOR EACH CONTROL 
BYTE 
*/ 
DECLARE 
CONTROLI 
BYTE DATA 
(073H); 
DECLARE 
CONTROL2 
BYTE 
DATA 
(053H); 


/* DECLARE 
TIME 
INTERVAL 
*/ 
DECLARE 
TIME$INTERVAL 
ADDRESS 
DATA 
(1); 


/* RESERVE 
SPACE 
FOR THE CURRENT 
BELT 
SPEED 
*/ 
DECLARE 
BELT$SPEED 
BYTE; 


/* RESERVE 
SPACE 
FOR THE CURRENT 
BELT WEIGHT 
*/ 
DECLARE 
BELT$WEIGHT 
ADDRESS; 


/* RESERVE 
SPACE 
FOR THE 
LIQUID 
FLOW 
*/ 
DECLARE 
LIQUID$FLOW 
ADDRESS; 


/* RESERVE 
SPACE 
FOR THE EFFECTIVE 
SETPOINT 
*/ 
DECLARE 
MASS$SETPOINT 
ADDRESS; 


/* RESERVE 
SPACE 
FOR THE DESIRED 
SETPOINT 
*/ 
DECLARE 
SET$POINT 
ADDRESS; 


/* RESERVE 
SPACE 
FOR THE DISTANCE 
OF BELT 
PER REVOLUTION 
*/ 


/* DEFINE 
THE'CONVEYOR 
LENGTH */ 
DECLARE 
CONV$LENGTH 
BYTE DATA 
(200); 


/* DEFINE 
THE CONSTANT 
SIX */ 
DECLARE 
SIX BYTE DATA 
(6); 


/* RESERVE 
STORAGE 
FO~ ACTUAL 
CURRENT 
MASS 
FLOW 
*/ 
DECLARE 
MASS$FLOW 
ADDRESS; 


127 
1 


128 
1 


133 
1 
134 
1 


135 
1 


136 
1 


137 
1 


138 
1 


141 
2 


142 
2 


/* RESERVE 
SPACE 
FOR BELT CONTROL 
OUTPUT 
*/ 
DECLARE 
BELT$CONTROL 
ADDRESS; 


/* RESERVE 
SPACE 
FOR LIQUID 
RATIO 
*/ 
DECLARE 
LIQUID$RATIO 
BYTE; 


/* RESERVE 
SPACE 
FOR LIQUID CONTROL 
OUTPUT 
*/ 


DECLARE 
LIQUID$VALVE 
ADDRESS; 


/* RESERVE 
SPACE 
FOR RUN/HALT 
CONTROL 
*/ 
DECLARE 
SYSTEM$RUNNING 
BYTE PUBLIC; 


/* RESERVE 
SPACE 
FOR ERROR 
FIELD 
*/ 
DECLARE 
ERROR$FIELD 
ADDRESS 
DATA 
(0F800H); 


DECLARE 
DUMMY 
ADDRESS; 


/* RESERVE 
SPACE 
FOR PIC ICW BYTE */ 
DECLARE 
ICW BYTE; 


/* DEFINE 
CONSTANT 
1000 */ 
DECLARE 
THOUSAND 
ADDRESS 
DATA 
(1000); 


/* DEFINE 
CONSTANT 
0 */ 
DECLARE 
ZERO ADDRESS 
DATA 
(0); 


/* DEFINE 
INTERRUPT 
JUMP 
TABLE 
*/ 
DECLARE 
JUMP$TABLE 
BYTE AT 
(3F00H); 


/* DECLARATION 
OF PIC ADDRESSES 
ON ISBC 569 BOARD 
*/ 


DECLARE 
PIC$ICW1$PTR 
LITERALLY 
'0ECH'; 
DECLARE 
PIC$ICW2$PTR 
LITERALLY 
'0EDH'; 


DECLARE 
PIC$INT$MASK$PTR 
LITERALLY 
'0EDH'; 


/* DECLARATION 
OF PIC CONSTANTS 
*/ 
DECLARE 
CLR$LOW$BITS 
LITERALLY 
'0E0H'; 


DECLARE 
INTERVAL$4 
LITERALLY 
'016H'; 


DECLARE 
INTERRUPT$MASK 
LITERALLY 
'0F4H'; 
$EJECT 
/******************************************* 
* 
INITIALIZE 
PROGRAM AT START-UP 
OF SYSTEM * 


* THIS 
PROCEDURE 
IS CALLED 
AT START-UP 
* 
*******************************************/ 


/* DISABLE 
THE 
INTERRUPTS 
*/ 
DISABLE; 


/* INITIALIZE 
PID RECORD 
*/ 
CALL 
UQPSET 
(.PRCV,.ERROR$FIELD,.DUMMY); 
CALL 
UQPSET 
(.PRLQ,.ERROR$FIELD,.DUMMY); 


143 
144 


145 
146 
147 
148 
149 
150 


151 
152 
153 
154 
155 
156 


157 
158 
159 


160 
161 


162 
163 


164 
165 


/* INITIALIZE 
THE CONTROL 
BITS 
*/ 
CALL UQPSCT 
(.PRCV,.CONTROLl); 
CALL UQPSCT 
(.PRLQ,.CONTROL2); 


/* SET UP THE PID CONSTANTS 
*/ 
CONSTANTSl.C0 
FEEDER$C0; 
CONSTANTSl.Cl 
FEEDER$Cl; 
CONSTANTSl.C2 
FEEDER$C2; 
CONSTANTSl.C3 
FEEDER$C3; 
CONSTANTSl.DT 
FEEDER$TIME$INTERVALj 
CONSTANTSl.S 
FEEDER$SCALE$FACTORj 


CONSTANTS2.C0 
CONSTANTS2.Cl 
CONSTANTS2.C2 
CONSTANTS2.C3 
CONSTANTS2.DT 
CONSTANTS2.S 


LIQUID$C0 j 
LIQUID$Clj 
LIQUID$C2 ; 
LIQUID$C3j 
LIQUID$TIME$INTERVALj 
LIQUID$SCALE$FACTOR; 


/* CLEAR 
SETPOINTS 
*/ 
SETPOINT 
= 0; 
LIQUID$RATIO 
= 
0j 
SYSTEM$RUNNING 
= 0; 


/* INITIALIZE 
THE CONSTANTS 
*/ 
CALL UQPSCN 
(.PRCV,.CONSTANTSl); 
CALL 
UQPSCN 
(.PRLQ,.CONSTANTS2)j 


/* 
INITIALIZE 
THE BOUNDS 
*/ 
CALL UQPSBD 
(.PRCV,.BOUNDSl); 
CALL UQPSBD 
(.PRLQ,.BOUNDS2); 


/* SET THE TIME 
INTERVAL 
*/ 
CALL 
UQPSTI 
(.PRCV,.TIME$INTERVAL)j 
CALL UQPSTI 
(.PRLQ,.TIME$INTERVAL) 
j 


/* INITIALIZE 
PROCESSOR 
0 */ 
CALL 
PROCESSOR$0$INITIALIZATIONj 


/* INITIALIZE 
PROCESSOR 
1 */ 
CALL 
PROCESSOR$l$INITIALIZATIONj 
/* INITIALIZE 
PROCESSOR 
2 */ 
CALL PROCESSOR$2$INITIALIZATION; 


/* INITIALIZE 
COUNTER 
1 */ 
CALL COUNTER$I$INITIALIZATIONj 


/* INITIALIZE 
COUNTER 
2 */ 
CALL COUNTER$2$INITIALIZATION; 


/* INITIALIZE 
INTERRUPT 
CONTROLLER 
*/ 
ICW = 
(LOW (.JUMP$TABLE) 
AND 
CLR$LOW$BITS 
) OR 
INTERVAL$4 
j 
OUTPUT 
(PIC$ICWl$PTR) 
= 
ICW; 


173 
174 


186 
187 
188 
189 
190 
191 


192 
193 


ICW = HIGH 
(.JUMP$TABLE)i 
OUTPUT 
(PIC$ICW2$PTR) 
= ICWi 


/* SET 
INTERRUPT 
MASKS 
*/ 


OUTPUT 
(PIC$INT$MASK$PTR) 


/* ENABLE 
INTERRUPTS 
*/ 
ENABLEi 


/* RETURN 
TO MAIN 
PROGRAM 
*/ 


'RETURNi 


END INITIATIONi 
$EJECT 
/*************************************************** 
* 
THIS 
IS THE PID CONTROL 
ROUTINE. 
IT IS ENTERED * 
* 
EACH 200 MILLISECONDS 
THROUGH 
AN 
INTERRUPT 
GEN- * 


* 
ERATED 
BY THE FREQUENCY 
COUNTER 
UPI AND SENT TO * 


* 
INTERRUPT 
3. 
* 


*********************************w*****************/ 


/* TURN THE 
LED INDICATOR 
ON */ 


OUTPUT (RESET$LATCH$ADR) 
= INDICATOR$ONi 


/* GET WEIGHBELT 
WEIGHT 
*/ 


BELT$WEIGHT=WEIGHBELT$WEIGHTi 


/* GET LIQUID 
FLOW RATE 
*/ 


LIQUID$FLOW=LIQUID$FLOW$RATEi 


/* CONTROL 
START-STOP 
RAMP */ 


IF SYSTEM$RUNNING 
THEN MASS$SETPOINT~SETPOINTi 
ELSE MASS$SETPOINT=0i 


/* DETERMINE 
ACTUAL 
MASS 
FLOW 
ON WEIGHBELT 
*/ 


CALL MQULD2(.IR,.BELT$CONTROL) 
i 
CALL MQUML2(.IR,.BELT$WEIGHT)i 
CALL MQUML1(.IR,.DIST$REV)i 
CALL MQUDVl(.IR,.CONV$LENGTH)i 
CALL 
MQSDV2(.IR,.THOUSAND)i 
CALL MQSST2(.IR,.MASS$FLOW)i 


/* COMPUTE 
ERROR SIGNAL 
ON WEIGHBELT 
*/ 


CALL MQSLD2(.IR,.MASS$SETPOINT)i 
CALL MQSSB2(.IR,.MASS$FLOW)i 


/* HANDLE 
PID BELT CONTROL 
ALGORITHM 
*/ 


CALL 
UQPPID(.PRCV,.IR)i 


/* STORE 
OUTPUT 
SIGNAL 
*/ 
CALL MQUST2(.IR,.BELT$CONTROL)i 
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197 
198 


201 
2 


202 
2. 


203 
2 


204 
2 


205 
2 


206 
2 


207 
2 


208 
2 
209 
2 
210 
1 


/* 
COMPUTE 
LIQUID 
SETPOINT 
*/ 
CALL 
MQSLD2(.IR,.MASS$FLOW)i 
CALL 
MQSML1(.IR,.LIQUID$RATIO)i 
CALL 
MQSML1(.IR,.SIX)i 


/* VERIFY 
THAT 
WEIGHBELT 
IS 
MOVING 
*/ 
IF 
WEIGHBELT$SPEED 
= 
0 
THEN 
CALL 
MQULD2(.IR,.ZERO)i 


/* COMPUTE 
LIQUID 
ERROR 
*/ 
CALL 
MQSSB2(.IR,.LIQUID$FLOW)i 


/* HANDLE 
PID 
LIQUID 
CONTROL 
*/ 
CALL 
UQPPID(.PRLQ,.IR); 


/* 
STORE 
OUTPUT 
SIGNAL 
*/ 
CALL 
MQUST1(.IR,.LIQUID$VALVE)i 


/* OUTPUT 
WEIGHBELT 
CONTROL 
SIGNAL 
*/ 
CALL 
WEIGHBELT$MOTOR$DRIVE 
(BELT$CONTROL)i 


/* OUTPUT 
FLOW 
CONTROL 
SIGNAL 
*/ 
CALL 
LIQUID$VALVE$POSITION 
(LIQUID$VALVE)i 


/* SEND 
END 
OF 
INTERRUPT 
TO 
8259 
CONTROLLER 
*/ 


OUTPUT(0ECH)=020Hi 


/* TURN 
THE 
LED 
INDICATOR 
OFF 
*/ 
OUTPUT 
(RESET$LATCH$ADR) 
INDICATOR$OFFi 


/* RETURN 
FROM 
CONTROL 
TASK 
*/ 
RETURNi 
END 
PIDRUN; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


465 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


01C 1H 
0094H 
000AH 


4490 
1480 
100 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
PROCESSORINITIALIZATIONMODULE 


OBJECT MODULE 
PLACED 
IN :F1:SBC941.0BJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:F1:SBC941.PLM 
DEBUG 
PAGEWIDTH(72) 
TITLE('PR 
-OCESSOR 
INITIALIZATION') 


/********************************************** 
* THIS 
PROGRAM 
IS USED TO INITIALIZE 
THE ISBC * 
* 
941 PROCESSOR 
INSTALLED 
IN SOCKET 
0. 
THE * 
* DEVICE 
WILL 
OPERATE 
IN THE FREQUENCY 
OUTPUT * 


* MODE. 
* 
**********************************************/ 


/* DECLARATION 
OF ADDRESSES 
*/ 
DECLARE 
UPI$0$STATUS 
LITERALLY 
'0ESH'; 
DECLARE 
UPI$0$COMMAND 
LITERALLY 
'0ESH'; 
DECLARE 
UPI$0$DATA 
LITERALLY 
'0E4H'; 


DECLARE 
UPI$l$STATUS 
DECLARE 
UPI$l$COMMAND 
DECLARE 
UPI$l$DATA 


LITERALLY 
'0E7H'; 
LITERALLY 
'0E7H'; 
LITERALLY 
'0E6H'; 


LITERALLY 
'0E9H'; 
LITERALLY 
'0E9H'; 
LITERALLY 
'0E8H'; 


COMMANDS 
*/ 


LITERALLY 
'00BH'; 
LITERALLY 
'00DH'; 
LITERALLY 
'00EH'; 
LITERALLY 
'00SH'; 
LITERALLY 
'004H'; 
LITERALLY 
'002H'; 
LITERALLY 
'001H'; 
LITERALLY 
'006H'; 


/* DECLARATION 
OF 
DECLARE 
RFC 
DECLARE 
IBF 
DECLARE 
QF' 


ISBC 941 STATUS 
BITS 
*/ 


LITERALLY 
'080H'; 
LITERALLY 
'002H'; 
LITERALLY 
'010H'; 


#0 INITIALIZATION 
LITERALLY 
'0BSH'; 
LITERALLY 
'000H'; 
LITERALLY 
'001H'; 
LITERALLY 
'000H'; 
LITERALLY 
'001H'; 
LITERALLY 
'000H'; 
LITERALLY 
'00EH'; 


DECLARE 
UPI$2$STATUS 
DECLARE 
UPI$2$COMMAND 
DECLARE 
UPI$2$DATA 


/* DECLARATION 
OF ISBC 941 
DECLARE 
SETP1 
DECLARE 
CLRP1 
DECLARE 
CLRP2 
DECLARE 
PAUSE 
DECLARE 
LOOP 
DECLARE 
INITPF 
DECLARE 
PACIFY 
DECLARE 
ENFLAG 


/* 
DECLARATION 
OF ISBC 941 
DECLARE 
FREQ 
DECLARE 
SF 
DECLARE 
OUTPUT$ENABLE0 


DECLARE 
INITIAL$STATE 
DECLARE 
DELAY 
DECLARE 
PERIOD 
DECLARE 
INITIAL$OUTPUT 


/* DECLARATION 
OF INTERVAL 
DECLARE 
PIT$0$MODE 
DECLARE 
PIT$0$INTERVAL 
DECLARE 
PIT$0$MODE$WRD 
DECLARE 
PIT$0$COUNT 


TIMER 
PARAMETERS 
*/ 
LITERALLY 
'016H'; 
LITERALLY 
'00EH'; 
LITERALLY 
'0E3H'; 
LITERALLY 
'0E0H'; 


/* DECLARATION 
OF COUNTER 
LOCATIONS 
*/ 
DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE 
EXTERNAL; 


/* DECLARATION 
OF ISBC 941 PRIMARY 
DATA */ 
DECLARE 
INIT$0$TABLE(6) 
BYTE DATA 
( 
FREQ, 
SF, 
OUTPUT$ENABLE0, 
INITIAL$STATE, 
DELAY, 
PERIOD 
); 


/* DECLARATION 
OF MISC 
PARAMETERS 
*/ 
DECLARE I BYTE; 


/*********************************************** 
* 
INITIALIZATION 
PROGRAM BODY 
* 
***********************************************/ 


PROCESSOR$0$INITIALIZATION: 
PROCEDURE 
PUBLIC; 


/* INITIALIZE 
~OUNTER 
0 FOR 
10 MICROSECONDS 
*/ 
OUTPUT(PIT$0$MODE$WRD)=PIT$~$MODE; 
OUTPUT(PIT$0$COUNT)=PIT$0$INTERVAL, 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET */ 
DO WHILE 
(INPUT(UPI$0$STATUS) 
AND 
RFC) 
= 0); 


DO WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$0$COMMAND)=PACIFY; 
END; 


/* REQUEST 
PRIMARY 
FUNCTION 
*/ 
DO WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT(UPI$0$COMMAND)= 
INITPF; 


/* LOAD 
INITIAL 
PARAMETERS 
*/ 
DO I=0 TO 
5; 
DO WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT(UPI$0$DATA)=INIT$0$TABLE(I); 
END; 


/* TERMINATE 
PARAMETER 
LOADING 
*/ 
DO WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 
END; 
OUTPUT (UPI$0$COMMAND)=PAUSE; 


END; 
OUTPUT (UPI$0$COMMAND)=LOOP; 


/* SET UNUSED 
BITS TO ALLOW 
EXPANSION 
*/ 


DO WHILE 
(INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 
END; 
OUTPUT (UPI$0$COMMAND)=CLRP2; 


DO WHILE 
(INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 
END; 
OUTPUT (UPI$0$DATA)=INITIAL$OUTPUT; 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 
RETURN; 


END PROCESSOR$0$INITIALIZATION; 
$EJECT 
/************************************************ 
* THIS 
PROCEDURE 
IS USED TO 
INITIALIZE 
THE 
ISBC * 
* 
941 PROCESSOR 
INSTALLED 
IN SOCKET 
1. 
THE DE- * 
* VICE WILL 
OPERATE 'IN THE 
FCOUNT, 
HIGH 
FRE- * 
* QUENCY 
INPUT MODE. 
* 
************************************************/ 


/* DEFINE 
INITIALIZATION 
PARAMETERS 
*/ 
DECLARE 
FCOUNT 
LITERALLY 
'033H'; 
DECLARE 
INPUT$SELECT 
LITERALLY 
'001H'; 
DECLARE 
OUTPUT$ENABLE$l 
LITERALLY 
'001H'; 
DECLARE 
SAMPLING$INTERVAL 
LITERALLY 
'009H'; 
DECLARE 
INITIAL$STATE$l 
LITERALLY 
'0EIH'i 


/* DECLARE 
PARAMETER 
INITIALIZATION 
TABLE 
*/ 
DECLARE 
INIT$1$TABLE(4) 
BYTE DATA 
( 
FCOUNT, 
INPUT$SELECT, 
OUTPUT$ENABLE$l, 
SAMPLING$INTERVAL 
); 


/************************************************ 
* 
INITIALIZATION 
BODY 
* 
************************************************/ 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET */ 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
RFC) = 0); 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
IBF) <> 
0); 
END; 
OUTPUT (UPI$l$COMMAND)=PACIFY; 
END; 


I"'''' 
1"'1 
1 "'2 
1"'3 
1"'4 
1"'5 
1"'6 
1"'7 
1"'8 
1"'9 
11'" 


/* 
REQUEST 
PRIMARY 
FUNCTION 
*/ 


DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBFI 
<> 
"'I; 
END; 
OUTPUT 
(UPI$l$COMMANDI=INITPF; 


/* 
LOAD 
INITIAL 
PARAMETERS 
*/ 
DO 
I=0 
TO 
3; 
DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBFI 
<> 
"'I; 


END; 
OUTPUT 
(UPI$l$DATAI=INIT$l$TABLE 
(II; 


END; 


/* TERMINATE 
PARAMETER 
LOADING 
*/ 


DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBFI 
<> 
01; 
END; 
OUTPUT 
(UPI$l$COMMANDI=PAUSE; 


/* SET 
UNUSED 
BITS 
HIGH 
FOR 
SPARE 
ENABLES 
*/ 
DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBFI 
<> 
"'I; 


END; 
OUTPUT 
(UPI$l$COMMANDI 
=SETP1; 


DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBFI 
<> 
01; 


END; 
OUTPUT 
(UPI$l$DATAI=INITIAL$STATE$l; 


/* 
START 
FREQUENCY 
COUNT 
OPERATION 
*/ 


DO 
WHILE 
((INPUT(UPI$l$STATUSI 
AND 
IBF) 
<> 
01; 


END; 
OUTPUT 
(UPIS1$COMMAND)=LOOP; 


/* RETURN 
TO 
CALLING 
PROGRAM 
*/ 
RETURN; 


END 
PROCESSOR$l$INITIALIZATION; 


$EJECT 
/************************************************ 
* 
THIS 
PROCEDURE 
IS 
USED 
TO 
INITIALIZE 
THE 
ISBC 
* 
* 
941 
INSTALLED 
IN 
SOCKET 
2. 
THE 
DEVICE 
WILL 
BE * 


* 
OPERATED 
AS 
A 
STEPPER 
MOTOR 
DRIVER. 
* 


************************************************/ 


LITERALLY 
'017H'; 


LITERALLY 
''''DFH'; 
LITERALLY 
'0F0H'; 
LITERALLY 
'QJ50H'; 


LITERALLY 
'004H'; 


LITERALLY 
'QJQJ0H'; 


LITERALLY 
'''''''0H'; 
LITERALLY 
'QJ",eH'; 


LITERALLY 
''''0'''H'; 


LITERALLY 
''''QJQJH'; 
LITERALLY 
''''QJQJH'; 


DECLARE 
STEPPER 


DECLARE 
SCALE$FACTOR 
DECLARE 
OUTPUT$ENABLE$2 


DECLARE 
OUTPUT$POLARITY 


DECLARE 
COMMON$PERIOD 


DECLARE 
P2QJ$TRAN1 


DECLARE 
P2QJ$TRAN2 


DECLARE 
P21$TRAN1 


DECLARE 
P21$TRAN2 


DECLARE 
P22$TRAN1 
DECLARE 
P22$TRAN2 


111 
1 
DECLARE 
P23$TRAN1 
LITERALLY 
,000H' ; 
112 
1 
DECLARE 
P23$TRAN2 
LITERALLY 
'000H'; 
113 
1 
DECLARE 
P24$TRAN1 
LITERALLY 
'000H '; 
114 
1 
DECLARE 
P24$TRAN2 
LITERALLY 
,002H' ; 


115 
1 
DECLARE 
P25$TRAN1 
LITERALLY 
'000H'; 
116 
1 
DECLARE 
P25$TRAN2 
LITERALLY 
'002H'; 
117 
1 
DECLARE 
P26$TRAN1 
LITERALLY 
'001H'; 
118 
1 
DECLARE 
P26$TRAN2 
LITERALLY 
'0e3H'; 
119 
1 
DECLARE 
P27$TRAN1 
LITERALLY 
'001H'; 
120 
1 
DECLARE 
P27$TRAN2 
LITERALLY 
'0f113H' 
; 


121 
1 
DECLARE 
CLR$LOW$PORT 
LITERALLY 
'0eFH'; 


/* DECLARE 
PARAMETER 
INITIALIZATION 
TABLE 
*/ 
DECLARE 
INIT$2$TABLE(21) 
BYTE DATA 
( 
STEPPER, 
SCALE$FACTOR, 
OUTPUT$ENABLE$2, 
OUTPUT$POLARITY, 
COMMON$PERIOD, 
P2e$TRAN 1, 
P20$TRAN2, 
P21$TRAN1, 
P21$TRAN2, 
P22$TRAN 1, 
P22$TRAN2, 
P23$TRAN1, 
P23$TRAN2, 
P24$TRAN1, 
P24$TRAN2, 
P25$TRAN 1, 
P25$TRAN2, 
P26 $TRAN 1, 
P26$TRAN2, 
P27 $TRAN 1, 
P27$TRAN2 
); 
/************************************************ 
* 
INITIALIZATION 
BODY 
* 
************************************************/ 


123 
1 
PROCESSOR$2$INITIA~IZATION: 
PROCEDURE 
PUBLIC; 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET 
*/ 


124 
2 
DO WHILE 
((INPUT(UPI$2$STATUS) 
AND 
RFC) = 0) ; 


125 
3 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) <> 
0); 
126 
4 
END; 


127 
3 
OUTPUT (UPI$2$COMMAND)=PACIFY; 


128 
3 
END; 


/* REQUEST 
PRIMARY 
FUNCTION 
*/ 


129 
2 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) <> 
0) ; 
130 
3 
END; 


131 
2 
OUTPUT(UPI$2$COMMAND)=INITPF; 


132 
133 
134 
135 
136 


137 
138 
139 


14f1l 
141 
142 


143 
144 
145 
146 
147 
148 


/* 
LOAD 
INITIAL 
PARAMETERS 
*/ 
DO 
I=fIlTO 
2f1l; 
DO 
WHILE 
((INPUT(UPI$2$STATUS) 
AND 
I~F) 
<> 
fIl); 
END; 
OUTPUT(UPI$2$DATA)=INIT$2$TABLE(I); 
END; 


/* 
TERMINATE 
PARAMETER 
LOADING 
*/ 
DO 
WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
fIl); 
END; 
OUTPUT 
(UPI$2$COMMAND)=PAUSE; 


/* 
START 
STEPPER 
CONTROLLER 
OPERATION 
*/ 
DO 
WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
fIl); 
END; 
OUTPUT 
(UPI$2$COMMAND)=LOOP; 


/* 
SET 
UNUSED 
BITS 
LOW 
TO 
ENABLE 
GENERAL 
FUNCTIONS 
*/ 
DO 
WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
fIl); 
END; 
OUTPUT(UPI$2$COMMAND)=CLRP1; 
DO 
WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
fIl); 
END; 
OUTPUT 
(UPI$2$DATA)=CLR$LOW$PORT; 


/* 
RETURN 
TO 
CALLING 
PROGRAM 
*/ 
RETURN; 


END 
PROCESSOR$2$INITIALIZATION; 


$EJECT 
/*********************************************** 
* THIS 
PROCEDURE 
IS 
USED 
TO 
INITIALIZE 
COUNTER 
* 
* 
1 TO 
PERFORM 
AS 
AN 
EIGHT 
BIT 
BINARY 
COUNTER 
* 
* WHICH 
WILL 
BE 
USED 
TO 
MEASURE 
THE 
BELT 
SPEED.* 
***********************************************/ 


/* 
INITIALIZE 
COUNTER 
1 FOR 
EIGHT 
BIT 
COUNTING 
*/ 
LIQ$COUNT 
= 
f1l; 


/* 
RETURN 
TO 
CALLING 
PROGRAM 
*/ 
RETURN; 


END 
COUNTER$l$INITIALIZATION; 


$EJECT 
/*********************************************** 
* THIS 
PROCEDURE 
IS 
USED 
TO 
INITIALIZE 
COUNTER 
* 
* 
2 TO 
PERFORM 
AS 
AN 
EIGHT 
BIT 
BINARY 
COUNTER 
* 
* WHICH 
WILL 
BE 
USED 
TO 
MEASURE 
THE 
LIQUID 
* 
* 
FLOW 
THROUGH 
THE 
METER. 
* 
***********************************************/ 


155 
1 
COUNTER$2$INITIALIZATION: 
PROCEDURE 
PUBLIC; 


'/* 
INITIALIZE 
COUNTER 
2 FOR EIGHT BIT COUNTING 
*/ 


156 
2 
BELT$COUNT 
= 0 ; 


/* 
RETURN 
TO CALLING 
PROGRAM */ 


157 
2 
RETURN; 


158 
2 
END COUNTER$2$INITIALIZATION; 
159 
1 
END PROCESSOR$INITIALIZATION$MODULE; 
$EJECT 


CODE AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK SIZE 


329 LINES READ 
o PROGRAM 
ERROR(S) 


0201H 
0001H 
0000H 


513D 
1D 
0D 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
PROCESSORINTERFACEMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:F1:0PR941.0BJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:F1:0PR941.PLM 
DEBUG 


$INTVECTOR(4,3F00H) 
$PAGEWIDTH(72) 
$TITLE('PROCESSOR 
INTERFACE') 
/********************************************** 
* 
THESE 
PROGRAMS 
PROVIDE 
THE 
OPERATING 
INTER- 
* 
* 
FACE 
BETWEEN 
THE 
APPLICATION 
PROGRAM 
AND 
* 
* 
THE 
ISBC 
941 
PROCESSORS 
OR 
COUNTERS. 
* 
**********************************************/ 


/* DECLARATION 
OF 
ADDRESSES 
*/ 
DECLARE 
UPI$0$STATUS 
LITERALLY 
'0E5H'; 
DECLARE 
UPI$0$COMMAND 
LITERALLY 
'0E5H'; 


-DECLARE 
UPI$0$DATA 
LITERALLY 
'0E4H'; 


DECLARE 
UPI$l$STATUS 
DECLARE 
UPI$l$COMMAND 
DECLARE 
UPI$l$DATA 


LITERALLY 
'0E7H'; 
LITERALLY 
'0E7H'; 
LITERALLY 
'0E6H'; 


LITERALLY 
'0E9H'; 
LITERALLY 
'0E9H'; 
LITERALLY 
'0E8H'; 


COMMANDS 
*/ 
LITERALLY 
'00BH'; 
LITERALLY 
'00DH'; 
LITERALLY 
'00EH'; 
LITERALLY 
'042H'; 
LITERALLY 
'043H'; 
LITERALLY 
'005H'; 
LITERALLY 
'004H'; 
LITERALLY 
'002H'; 
LITERALLY 
'001H'; 
LITERALLY 
'006H'; 
LITERALLY 
'071H'; 


STATUS 
BITS 
*/ 
LITERALLY 
'080H'; 
LITERALLY 
'002H'; 
LITERALLY 
'001H'; 
LITERALLY 
'010H'; 
LITERALLY 
'020H'; 


/* DEFINE 
THE 
MATH 
ROUTINES 
USED 
BY 
MODULES 
*/ 
MQULD4: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END 
MQULD4; 
MQUDV2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END 
MQUDV2; 


DECLARE 
UPI$2$STATUS 
DECLARE 
UPI$2$COMMAND 
DECLARE 
UPI$2$DATA 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
SETP1 
DECLARE 
CLRP1 
DECLARE 
CLRP2 
DECLARE 
RDFCtP 
DECLARE 
RDFC1 
DECLARE 
PAUSE 
DECLARE 
LOOP 
DECLARE 
INITPF 
DECLARE 
PACIFY 
DECLARE 
ENFLAG 
DECLARE 
SETOE 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
RFC 
DECLARE 
IBF 
DECLARE 
OBF 
DECLARE 
QF 
DECLARE 
QNE 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END MQUDV1; 
MQUST1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END MQUST1; 


/* DEFINE 
THE MATH ACCUMULATOR 
STORAGE 
AREA 
*/ 


DECLARE 
IR(18) 
BYTE 
EXTERNAL; 


/* DEFINE 
THE COUNTER 
LOCATIONS 
*/ 


DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE EXTERNAL; 


$EJECT 
/************************************************ 
* THIS 
PROGRAM 
IS USED TO GENERATE 
A FREQUENCY 
* 


* OUTPUT 
USING THE ISBC 941 MODULE 
INSTALLED 
IN * 


* SOCKET 
NUMBER 
0. 
TO PROVIDE 
MAXIMUM 
RESOLU- 
* 


* TION, 
FOUR PERIODS WILL 
BE USED. 
THE FREQUEN-* 


* CY RANGES 
CORRESPONDING 
TO EACH 
PERIOD ARE: 
* 


* 
RANGE 
FREQ 
RESOLUTION 
* 


* 
1 
50 TO 
165HZ 
2 HZ 
* 


* 
2 
166 TO 
225 HZ 
3 HZ 
* 


* 
3 
226 TO 285 HZ 
3 HZ 
* 


* 
4 
286 TO 
550 HZ 
6 HZ 
* 


* THE SCALE 
FACTOR 
IS COMPUTED 
BY THE FORMULA: 
* 


* 
SF=100000/((FREQ)*(RANGE 
FACTOR)) 
* 


************************************************/ 


/* DECLARATION 
OF CONSTANT, 
100,000 
*/ 


DECLARE 
HUNDRED$K(4) 
BYTE DATA 
( 
0A0H,086H,001H,000H 
); 


/* DECLARATION 
OF ISBC941 
PORT ENABLES 
*/ 


DECLARE 
ENABLE$FREQ 
LITERALLY 
'01H'; 
DECLARE 
DISABLE$FREQ 
LITERALLY 
'00H'; 


/* DECLARATION 
OF ISBC 941 MEMORY 
LOCATION 
COMMANDS 
*/ 


DECLARE WRRM$55 
LITERALLY 
'055H'; 


,DECLARE WRRM$74 
LITERALLY 
'074H'; 


/* DECLARATION 
OF VARIABLES 
USED 
IN COMPUTATIONS 
*/ 


DECLARE 
(RANGE,FREQA) 
BYTE; 
DECLARE 
FREQ ADDRESS; 


/* BEGIN COMPUTATION 
OF OUTPUT 
FOR FREQ 
> 
48 HZ. */ 


IF FREQ > 49 
THEN 
DO; 


/* ENABLE 
FREQUENCY 
OUTPUT 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= SETOE; 


54 
3 
DO 
WHILE 
( (INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0) ; 


-55 
4 
END; 
56 
3 
OUTPUT 
(UPI$0$DATA) 
= 
ENABLE$FREQ; 


/* COMPUTATION 
OF 
FREQUENCY 
RANGE 
*/ 


57 
3 
IF 
FREQ 
< 
285 
THEN 
DO; 
59 
4 
IF 
FREQ 
< 
226 
THEN 
DO; 
61 
5 
IF 
FREQ 
< 
166 
THEN 
RANGE 
9; 
63 
5 
ELSE 
RANGE 
= 
5 ; 
64 
5 
END; 
65 
4 
ELSE 
RANGE 
= 
3 ; 


66 
4 
END; 
67 
3 
ELSE 
RANGE 
= 
2; 


/* LOAD 
MATH 
ACCUMULATOR 
WITH 
100,000 
*/ 
68 
3 
CALL 
MQULD4 
(.IR,.HUNDRED$K); 


/* TEST 
FOR 
MOTOR 
SHUTDOWN 
*/ 
69 
3 
IF 
FREQ 
> 
1 
THEN 
DO; 


/* DIVIDE 
BY 
FREQUENCY 
*/ 
71 
4 
CALL 
MQUDV2 
(.IR,.FREQ); 


/* DIVIDE 
BY 
RNAGE 
FACTOR 
*/ 
72 
4 
CALL 
MQUDV1 
(.IR,.RANGE); 


/* GET 
TWO'S 
COMPLEMENT 
FOR 
ISBC 
941 
SCALE 
FACTOR 
*/ 


73 
4 
CALL 
MQUST1 
(.IR, .FREQA); 
74 
4 
FREQJI_= NOT 
(FREQA 
+ 
1); 
75 
4 
END; 


/* ADJUST 
FOR 
MOTOR 
STOP 
SIGNAL 
*/ 
76 
3 
ELSE 
DO; 
77 
4 
FREQA 
000H; 
78 
4 
RANGE 
0FFH; 
79 
4 
END; 


/* SEND 
NEW 
SCALE 
FACTOR 
TO 
DEVICE 
*/ 


80 
3 
DO 
WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0) ; 
81 
4 
END; 
82 
3 
OUTPUT(UPI$0$COMMAND) 
= WRRM$S5; 


83 
3 
DO 
WHILE 
( (INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0) ; 
84 
4 
END; 
85 
3 
OUTPUT 
(UPI$0$DATA) 
= FREQA; 


/* SEND 
NEW 
PERIOD 
TO 
DEVICE 
*/ 
86 
3 
DO 
WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0) ; 
87 
4 
END; 
88 
3 
OUTPUT 
(UPI$0$COMMAND) 
= WRRM$74; 


104 
105 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= RANGE; 


/* END OF FREQUENCY 
OUTPUT 
MODE 
*/ 


END; 


106 
107 
108 


109 
110 
III 


/* HANDLE 
FREQUENCIES 
< 
50 HZ. */ 


ELSE DO; 


/* DISABLE 
FREQUENCY 
OUTPUT GENERATION 
*/ 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= SETOE; 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= DISABLE$FREQ; 


/* END OF ALTERNATE 
FREQUENCY 
OUTPUT 
*/ 


END; 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 


RETURN; 


END WEIGHBELT$MOTOR$DRIVE; 


$EJECT 
/***************************************************** 
* THIS 
PROGRAM GETS 
THE WEIGHBELT 
WEIGHT 
FROM THE 
* 
* NUMBER 
1 ISBC 941 PROCESSOR. 
THE WEIGHT 
WILL 
BE 
* 


* RECEIVED 
AS A COUNT WHICH 
RANGES 
BETWEEN 
0 AND 
* 
* 
2000, CORRESPONDING 
TO A WEIGHT 
BETWEEN 
0.~ AND 
* 


* 
10.00 POUNDS. 
EACH COUNT 
RECEIVED 
HAS A VALUE 
* 
* OF 0.005 POUNDS. 
* 
*****************************************************/ 


/* DECLARATIONS 
OF VARIABLES 
USED 
IN THE 
PROCEDURE 
*/ 


DECLARE 
(LCOUNT,HCOUNT) 
BYTE; 
DECLARE WEIGHT 
ADDRESS; 


/* GET 
INPUT COUNT 
LOW BYTE 
*/ 


DO WHILE 
((INPUT(UPI$I$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$I$COMMAND) 
= RDFC0; 


DO WHILE 
((INPUT(UPI$I$STATUS) 
AND 
OBF) 
END; 
LCOUNT 
= 
INPUT(UPI$I$DATA); 


112 
113 
114 


115 
116 
117 


118 
119 
120 


121 
122 
123 


131 
132 


/* GET 
INPUT 
COUNT 
HIGH 
BYTE 
*/ 
DO 
WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 
END; 
OUTPUT 
(UPI$l$COMMAND) 
= RDFC1; 


DO 
WHILE 
«INPUT(UPI$l$STATUS) 
AND 
OBF) 
END; 
HCOUNT 
= 
INPUT(UPI$l$DATA); 


/* START 
NEXT 
WEIGHT 
SAMPLE 
PERIOD 
*/ 
DO 
WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 
END; 
OUTPUT 
(UPI$l$COMMAND) 
= 
LOOP; 


/* 
CONVERT 
WEIGHT 
WEIGHT 
WEIGHT 


WEIGHT 
TO 
AN 
ADDRESS 
HCOUNT; 
SHL(WEIGHT,8); 
WEIGHT 
+ 
LCOUNT; 


/* DIVIDE 
BY 
TWO 
TO 
CONVERT 
TO 
POUNDS 
*/ 
WEIGHT 
= SHR(WEIGHT,l); 


/* RETURN 
THE 
WEIGHTBELT 
WEIGHT 
*/ 
RETURN 
WEIGHT; 


END 
WEIGHBELT$WEIGHT; 


$EJECT 
/************************************************** 
* 
THIS 
PROCEDURE 
TRANFERS 
THE 
WEIGHBELT 
SPEED 
TO 
* 
* 
THE 
CALLING 
PROGRAM 
AND 
CLEARS 
THE 
COUNTER 
FOR 
* 
* 
THE 
NEXT 
TEST. 
THE 
SPEED 
RESOLUTION 
PROVIDES 
* 
* 
ONLY 
FIVE 
SPEED 
RANGES. 
* 
**************************************************/ 


WEIGHBELT$SPEED: 
PROCEDURE 
BYTE 
PUBLIC; 


/* DECLARATIONS 
OF 
VARIABLES 
USED 
BY 
THE 
PROCEDURE 
*/ 


DECLARE 
SPEED 
BYTE; 


/* LATCH 
COUNTER 
BEFORE 
READING 
SPEED 
*/ 


DISABLE; 


/* GET 
COUNTER 
VALUE 
FROM 
COUNTER 
*/ 


SPEED 
= BELT$COUNT; 


/* CLEAR 
COUNTER 
FOR 
NEXT 
OPERATION 
*/ 


BELT$COUNT 
0; 
ENABLE; 


/* 
RETURN 
DATA 
TO 
CALLING 
ROUTINE 
*/ 
RETURN 
SPEED; 


135 
1 


136 
2 


137 
2 


138 
2 


139 
2 


141 
3 


143 
4 


144 
4 
145 
.4 


146 
3 


147 
4 


148 
3 
149 
4 
150 
3 


151 
3 
152 
4 
153 
3 
154 
3 


155 
2 


156 
2 


$EJECT 
/*************************************************** 
* THIS 
PROCEDURE 
PROVIDES 
COMMANDS 
TO THE STEPPER 
* 
* MOTOR 
TO OPERATE 
THE CONTROL 
VALVE. 
IT WILL 
COM-* 
* PUTE THE SIGNED 
MAGNITUDE 
REPRESENTATION 
FROM 
* 
* THE 
TWO'S 
COMPLIMENT 
INPUT AND WILL 
ISSUE THE 
* 


* APPROPRIATE 
STEP 
INCREMENT 
AND DIRECTION. 
A 
* 
* 
FIXED 
STEP RATE 
OF 100 STEPS 
PER SECOND WILL 
BE 
* 


* USED BY THE CONTROL 
DEVICE. 
* 
***************************************************/ 


/* DECLARATIONS 
OF VARIABLES 
USED BY THE PROCEDURE 
*/ 
DECLARE 
POSITION 
BYTE; 


/* DEFINITIONS 
OF TERMS 
USED 
IN COMPUTATIONS 
*/ 


DECLARE 
STEP$RATE 
LITERALLY 
'005H'; 
DECLARE 
REVERSE 
LITERALLY 
'080H'; 


/* 
IF NO MOVEMENT, 
SKIP OPERATIONS 
*/ 
IF POSITION 
<> 
0 
THEN DO; 


/* SUPPORT 
CONVERSION 
TO SIGNED 
MAGNITUDE 
NUMBER 
*/ 


IF POSITION 
> 
127 
THEN 
DO; 


/* GET 
MAGNITUDE 
OF MOVEMENT 
*/ 


POSITION 
= 
256 - POSITION; 


/* SET SIGN FOR CCW ROTATION 
*/ 


POSITION 
= POSITION 
OR REVERSE; 
END; 


/* VERIFY 
THAT 
QUEUE 
SPACE 
IS AVAILABLE 
*/ 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
QF) 
<> 
0); 


END; 


/* REQUEST 
DESIRED 
STEP RATE 
*/ 


DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT(UPI$2$DATA) 
= STEP$RATE; 


/* REQUEST 
STEPPER MOVEMENT 
*/ 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 
END; 
OUTPUT (UPI$2$DATA) 
= POSITION; 
END; , 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 
RETURN; 


157 
1 


158 
2 
159 
2 


160 
2 


161 
2 


162 
2 
163 
2 


164 
2 
165 
2 
166 
2 
167 
2 
168 
2 


169 
2 


170 
2 


$EJECT 
/***************************************************** 
* THIS 
PROCEDURE 
TRANSFERS 
THE LIQUID 
FLOW 
RATE FROM * 


* THE 
FLOW COUNTER 
TO THE CALLING 
PROGRAM. 
AFTER 
* 
* READING, 
THE FLOW COUNTER 
WILL 
BE RESET 
TO FACILI- * 


* TATE 
THE NEXT 
READING. 
THE LIQUID 
FLOW COUNT WILL * 
* VARY BETWEEN 
20 AND 
240 PULSES 
IN EACH 
200 MILLI- 
* 
* SECOND 
SAMPLE 
INTERVAL. 
THIS WILL 
CORRESPOND 
TO 
* 
* THE ACTUAL 
LIQUID 
FLOW RATE 
OF 10 TO 
120 POUNDS 
* 
* PER MINUTE. 
* 


*****************************************************/ 


LIQUID$FLOW$RATE: 
PROCEDURE 
ADDRESS 
PUBLIC; 


/* DECLARATION 
OF VARIABLES 
USED BY THE 
PROGRAM 
*/ 
DECLARE 
TEMP 
BYTE; 


DECLARE 
(FLOW,T$TWO,T$SXTN,T$THRTWO) 
ADDRESS; 


/* LATCH 
COUNTER 
BEFORE 
READING 
FLOW */ 
DISABLE; 


/* GET 
FLOW RATE VALUE 
FROM COUNTER 
*/ 


TEMP 
= LIQ$COUNT; 


/* CLEAR COUNTER 
FOR NEXT 
OPERATION 
*/ 
LIQ$COUNT 
= 0; 
ENABLE; 


/* CONVERT 
TO POUNDS 
PER MINUTE 
*/ 
FLOW = TEMP; 
T$TWO = SHL(FLOW,I); 
T$SXTN 
= SHL(T$TWO,3); 


T$THRTWO 
= SHL(TSSXTN,I); 
FLOW = T$TWO 
+ T$SXTN 
+ T$THRTWO; 


/* RETURN 
FLOW 
RATE TO CALLING 
PROGRAM 
*/ 
RETURN 
FLOW; 


END LIQUID$FLOW$RATE; 


$EJECT 
/******************************************** 
* 
COUNTER 
FOR LIQUID 
FLOW RATE 
FROM 
LIQUID * 
* FLOW METER. 
COUNT PULSE WILL GENERATE 
AN * 
* 
INTERRUPT 
AT 
LEVEL 
1. 
* 


********************************************/ 


171 
1 
LIQ$CNT: 
PROCEDURE 
INTERRUPT 
1 PUBLIC; 


/* INCREMENT 
FLOW COUNT 
*/ 
172 
2 
LIQ$COUNT 
= LIQ$COUNT 
+ 1; 


/* SEND 
END OF INTERRUPT 
*/ 


173 
2 
OUTPUT 
(0ECH) = 
020H; 


/* RETURN 
*/ 
RETURN; 


END LIQ$CNT; 


$EJECT 
/******************************************** 
* THIS 
PROCEDURE 
WILL 
PROVIDE 
AN EVENT COUN-* 
* TER TO HANDLE 
THE BELT MOTION 
DETECTOR. 
* 
* IT WILL 
OPERATE 
BY DIRECTING 
THE MOTION 
* 
* PULSE TO 
INTERRUPT 
2. 
* 
********************************************/ 


176 
1 
BELT$CNT: 
PROCEDURE 
INTERRUPT 
o PUBLIC; 


/* 
INCREMENT 
BELT MOVEMENT 
*/ 
177 
2 
BELT$COUNT 
= BELT$COUNT 
+ 1; 


/* SEND 
END OF INTERRUPT 
*/ 


178 
2 
OUTPUT 
(0ECH) = 020H; 


/* RETURN 
*/ 


179 
2 
RETURN; 


180 
2 
END BELT$CNT; 
181 
1 
END PROCESSOR$INTERFACE$MODULE; 
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Designing and Assembling 
, 
Microcomputer Systems Grows Easier 


Although 
a single 
data bus standard 
yet eludes 
the microcomputer 
industry. 
numer- 
ous manufacturers 
of single-board 
computer 
and supplementary 
boards 
have cast a 
hardware 
vote for the Multlbus. 
Intel's microcomputer 
backplane 
which they ongina- 
ted In 1976 
With a steady 
eye on the control 
industry 
market. 
Intel has designed 
a 
home to accommodate 
Multibus 
compatible 
equipment. 
the iCS-80 industrial 
chas- 
sis. It promises 
to slgniticantly 
reduce 
the time and cost of assembling 
the housing 
and Interface 
parts of a microcomputer-based 
control system. 
In this article. 
besides 
taking 
the first look at Intel's 
new chassis 
and Signal conditioning 
panels. we've put 
together 
a comprehensive 
list of Multibus 
compatible 
equipment. 


After 
the development 
of single-board 
computers 
nearly three years ago. ven- 
dors moved 
qUickly to seize a fraction 
of 
the market 
It seemed 
at first that every- 
thing 
from 
memories 
to 
analog 
I/O 
boards 
had become 
available. 
With an 
astonishing 
suddenness. 
companies 
sprang 
up In Silicon Valley. Texas. New 
Jersey. 
and along the forested 
roadside 
of Rt 
128 outside 
of Boston 
Late that 
year. 
we counted 
well over a hundred 
companies 
anxIous 
to make 
their 
for- 
tune seiling 
the control 
engineer 
every- 
thing 
from one or two interface 
boards 
to complete 
microprocessor 
systems 
Then 
the pleasant 
dream 
became 
a 
nightmare 
From power supply 
reqUire- 
ments 
to backplane 
pinouts. 
little was 
compatible 
Even such an obvious 
thing 
as board 
size 
differed 
from 
vendor 
to 
vendor 
and 
many 
a hope 
for an ideal 
system 
was 
crushed 
in a pragmatic 
search 
for whatever 
would 
fit together 
Seven 
months 
ago In our June 
1978 
Issue 
we noted 
that the number 
of mi- 
crocomputer 
system 
manufacturers 
had 
dwindled 
to about 
60 and 
since 
then. we find still fewer. Some. no doubt. 
were 
forced 
out 
for lack 
of reliability. 


though 
most. 
despite 
remarkably 
ta- 
lented 
englneenng, 
starved 
as the mar- 


ket saturaled 
Large 
scale 
integration 
of microcom- 
puter 
components 
has 
more 
than 
doubled 
the 
memory 
size 
01 slngle- 
board 
computers. 
Sixteen 
bit 
word 
lengths 
will 
become 
commonplace 
In 
the next year as microcomputer 
perfor- 
mance 
begins 
to 
rival 
the 
mini- 
computer's 
and 
the 
lines 
of distinc- 


tion between 
micros 
and miniS fades. 


The 
fight 
for a standard 
data 
bus 
drags 
on With leaders 
In the struggle 
but 
no winner 
On 
the 
offensive. 
Pro-Log 
and 
Mostek 
JOintly Introduced 
the STD 
bus last autumn 
In an attempt 
to gain a 
greater 
market 
share 
by espousing 
de- 


centralized 
system 
architectures 
Theil 
philosophy 
argues 
economics: 
the user 
should 
pay only for essential 
functions 
by selecting 
small, 
specialized 
boards 


and 
not squander 
funds 
on a general 
purpose 
board 
With extra 
features. 
Still. 
Intel, 
favonng 
more 
densely 
packed 
and versatile 
boards. 
continues 
to dominate 
the market 
while the Multi- 
bus 
retains 
its popularity. 
Today 
more 
30 
manufacturers 
produce 
over 
one 
hundred 
different 
boards 
based 
on that 
bus structure 
alone. Not that Intel enJoys 
the strict 
fidelity 
of its outside 
vendors; 
Digital 
Equipment 
Corporation. 
for In- 
stance. 
boasts 
some 
17 companies 
prOViding 
boards 
to 
mate 
With 
the 
LSI-11 
and 
LSI-112 


But perhaps 
alone among 
ItScompet- 
ItorS. Intel has recognized 
that the ma- 
JOrity of 
its boards 
are 
being 
used 
in 
Industrial 
applications 
and that the con- 
trol system 
designer 
needs 
more 
than 
components. 


An industrial 
chassis 


A microcomputer 
system 
designer 
must 
choose 
components 
that 
are 
electro- 
mechanically 
compatible. 
To that end. 


Intel IS IntrodUCing 
the ICS-80 Industnal 
chassIs 
and 
termination 
panels. 
It 
makes 
all 
Multibus-compatible 
CPU 


BASE 
UNIT 
INCLUDES 
4·SLOT 
MULTI 
BUS 
1M 
CARD 
CAGE 


$L10E1NIOUT 
MOUNTING 
FOR 
,SBC635(14AMP) 
or640 
(30 AMP) 


POWERSUPPLIES 


FOUR 
FANS 
TO 
IMPROVE 
COOLING 


-BOTH 
RETMA 
19" 


(FRONn 
AND 
NEMA 
(REAR) 
MOUNTING 
KITS 


, , 


/ 
,'11111 


MOUNTING 
SPACEFOR 
SIGNAL 
CONDITIONING 
TERMINATION 
PANELS 


Electronic 
Solutions 


Garry Manufacturing 


HT Instruments 


Hal Communications 
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most 
of the 
Interconnection 
and 
me- 
chanical 
details 
for 
assembling 
a 
microcomputer-based 
control 
system 
have 
already 
been 
worked 
out 
The ICS-80 stands 
15.75 inches 
high 
and 
can 
be 
mounted 
In a stardard 
RETMA 19 inch rack, or in a NEMA cabi- 
net secure 
from 
the Industrial 
environ- 


ment. The minimum 
layout consists 
of a 
four-slot 
Multlbus 
card 
cage with provI- 


sions 
for adding 
two more 
cages 
to a 
maximum 
of twelve 
cards. 
The cages 
fit 
vertically, 
like records 
In a rack, to aid 


convection 
cooling 
and permit 
front ac- 


cess 
for insertion 
and maintenance 


On 
the 
right 
side 
of the chassis 
IS 
room for either a 14 or 30 ampere 
power 
supply, 
fhe choice 
dictated 
by the bp- 


plication 
The 
system 
will 
operate 
on 
either 
115 or 230 volts with a range of 47 
to 63 Hertz 
specified 
in anticipation 
of 


International 
service. 


Cooling 
is assisted 
by four 
fans- 


three for the card cages 
and one for the 
power 
supply 
section. 
The 
intention 
here IS to make the installation 
of addi- 


tional 
fans 
unnecessary 
even after the 
system 
has expanded. 
The fans are ex- 
pected 
to provide 
adequate 
cooling 
for 
most applications 
so supplementary 
air 
conditioning 
can 
be eliminated 
or at 
least minimized 


Signal 
conditioning 


Three 
signal 
conditioning 
panels 
have 
been developed 
by Intel to simplify 
con- 
nections 
between 
the processing 
cards 
and the outside 
world. 
The principle 
is 
neatness, 
and with that follows 
reliabil- 
Ity. Flat ribbon 
cables 
connect 
the sig- 
nal conditioners 
to the processor 
cards. 


a safeguard 
from 
'whlch 
wire is which" 


and 
screwdriver 
slips 
In the vicinity 
of 
expensive 
boards. 
Field connections 
to 
the 
external 
inputs 
and 
outputs 
are 
made 
(presumably 
by electricians 
with 
big 
hands 
and 
reputations 
for being 
less 
than 
delicate) 
through 
rugged, 
screw-type 
barrier 
strips 
that 
accept 
wire as heavy 
as 14 AWG. 
The panels 
can 
mount 
either 
on 
RETMA 
cabinet 
brackets. 
NEMA wall spacers, 
or on the 
ICS-80 
chaSSIS Itself. 


Each 
signal 
condllionlng 
card 
gives 
the user a variety of options. The iCS-910 
analog 
signal 
conditioning 
'termination 
panel accepts 
up to 16 differential 
or 32 
Single 
ended 
Input 
channels. 
The four 
2-wire analog 
output 
channels 
might be 
connected 
to 4 to 20 mA current 
loops. 
The digital 
signal 
conditioning 
termi- 
nation 
panel. 
iCS-920, 
handles 
24 two- 
wire 
Input or output 
channels 
With sig- 
nals up to 55 V, 300 mA 
Inputs 
can be 
diode 
protected, 
and 
pads 
are 
pro- 


vided 
for current 
limiters 
or voltage 
di- 


Viders. Optoisolators 
may be inserted 
In 


ADAC Corp. 


Woburn, MA 
617/935-6668 
Advanced 
Micro Computers 
Santa Clara, CA 
408/732-2400 
Ampex 
EI Segundo, CA 
714/973-2970 
Analog Devices 
Norwood, MA 
617/329-4700 
Augat 
Attleboro, MA 
617/222-2202 
Burr-Brown 
Tucson, AZ 
602/655-8000 
Computer Marketing 
Waltham, MA 
617/894-7000 
Data Translalion 
Nalick, MA 
617/655-5300 
Datacube 
Reading. MA 
617/944-4600 
Datel Systems 
Canton, MA 
617/828-8000 
Electronic Solutions 
San Diego, CA 
714/292-0242 
Garry Manufacturing 
New Brunswick, NJ 
212/267-6844 
HT Instruments 


Marina Del Rey, CA 
312/822-4296 


Hal Communications 
Urbana, IL 
217/367-7373 


Heurtkon 


Madison, WI 
6081255-9075 
IDEAS 


Beltsville, MD 
301/937-3600 
Intel 
Aloha, OR 
503/642-2563 
Inlerphase 


Dallas, TX 
214/238-0971 


the DIP sockets 
for high voltage 
Isola- 
tion 
or Jumpers 
may 
be used 
Instead 
when 
the input 
IS TIL. 
Similarly, 
output 
sockets 
accept 
Jumpers 
for direct 
TTL 
output, 
DIP 
optoisolators 
for transient 
suppression, 
or integrated 
Circuit (open 
collector) 
drivers 
for 
high 
voltage' 
to 
high 
current 
outputs. 
Activity 
on each 
channel 
is indicated 
by LEOs 
The ac Signal 
conditioning 
(solidas) 
termination 
panel, 
iCS-930, 
Will actually 
work 
with ac or dc on ItS 16 channels. 


The user supplies 
optolsolators 
for Input 
Isolation 
and 
optically-Isolated 
solid 


Matrox Electronic Systems 
Montreal, Quebec 
514/735-1182 
Megalogic 


Brookville, OH 
513/833-5222 
Micro MemOries 
Chatsworth, CA 
213/998-0070 
Micro Networks 
Worcester, MA 
617/852-5400 
MlcroTec 
Sunnyvale, CA 
408/733- 2919 
MicrofTel 
St. Louis, MO 
314/569-3450 
Monolithic Systems 
Englewood, CO 
303/770-7400 
Motorola 
Austin, TX 
512/928-6572 
MUPRO 
Sunnyvale, CA 
4081737-0500 
National Semiconductor 
Santa Clara, CA 
4081737-5262 
North Star Computers 
Berkeley, CA 
415/549-0858 
Pertec (ICOM) 
Chatsworth, CA 
213/998-1800 
Relational Memory Systems 


San Jose, CA 
4081248-6356 
Systems, Computers and Interfaces 
Waltham, MA 
617/899-2359 
Thomas Engineering Co. 


Concord, CA 
415/686-3041 
Vector Electronic 
Sylmar, CA 
213/365-9661 
XEDAX 
Alameda, CA 
415/521-6600 
ZIA Tech 
Cupertino, CA 
4081996-7082 


state relays 
for output 
Isolation. 
Mount- 
Ing pads 
for customer-supplied 
MOVs 
or snubber 
networks 
are Included 
As 
before, 
a fuse gives overload 
protection 
and 
LEOs indicate 
channel 
activity 


The advantage 
of all this 
is that 
by 
plugging 
in some components 
and per- 
haps Inserting 
a few resistors 
and capa- 
citors. 
the Interface 
Units can be tailored 
to a particular 
application 
Since 
many 
mechanical 
and 
electrical 
connection 
problems 
have already 
been solved, 
a 
customized 
unit can 
be built With mini- 
mum 
effort. 
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Insite User's Program 
11 
Library 
. 


• Programs for 8048, 8080/8085, 
and 


8086/8087/8088 
Processors 
• Diskettes, Paper Tapes, and Listings 


Available for Library Programs 


• Accepted Program Submittals Entitle 


You to a Free Membership or Free 
Program Package 


• Program Library Catalog Offering 


Hundreds of Programs 


• Updates of New Programs Sent During 


Subscription Period 


Insite, 
Intel's 
Software 
Index and Technology 
Exchange 
Library, 
is a varied collection 
of programs 
and 
routines 
that have been written 
by users of Intel microcomputers, 
single-board 
computers, 
and develop- 
ment systems. 
This expanding 
library of programs 
covers a broad range of software 
tools that includes 
monitors, 
conversion 
routines, 
peripheral 
drivers, 
translators, 
math 
packages, 
and even games. 
As a 
library member, you can acquire a copy of any program within 
the library on any of its available 
types of 
media. By taking advantage of the availability 
of existing 
library programs, 
numerous 
hours of coding and 
debugging 
time can be saved and routine 
or redundant 
programming 
operations 
can be eliminated. 
The 
Insite Program Library also serves as a learning tool for individuals 
unfamiliar 
with assembly 
or high-level 
languages 
associated 
with Intel's 
family 
of microcomputers. 


Membership. 
Membership 
in Insite 
is available 
on an annual 
basis. 
Intel 
customers 
may become 
members 
through 
an accepted 
program contribution 
or paid membership 
fee. 


Program Submittals. The Insite Library is built on program submittals 
contributed 
by users. Customers 
are encouraged 
to submit 
their programs. 
For each accepted 
program, submittors 
will receive a choice 
of 
three free programs, 
or free membership 
with Insite for one year. (Forms and submittal 
requirements 
are 
attached.) 


Program Library Service. PAPER TAPES, DISKETTES OR SOURCE LISTINGS are available 
for every 
program in Insite. Diskettes 
are available on single or double density. 
Membership 
is required to purchase 
programs. 


Insite™ Program Library Catalog. Each member will be sent the Program Library Catalog consisting 
of an abstract 
for each program 
indicating 
the function 
of the routine, 
required 
hardware and software, 
and memory requirements. 


Insite members 
will be updated 
with abstracts 
of new programs 
submitted 
to the Library during 
the sub- 
scription 
period. For catalog and yearly subscription 
fee please refer to the Intel OEM Price List or contact 
the nearest Insite or Intel Sales Office. 


The following 
are trademarks 
of Intel Corporation 
and its .ffiliates 
and may be used only to ldenllfy 
Intel products: 
BXP, CREDIT, i.ICE, 
leS, im, Insita, Intel, INTEL, Intelevision, 
Intellee, 


iMMX, 
iOSP, iPOS, 
iRMX, 
iSeC, 
iSeX, 
Library 
Manager, 
MeS, 
MULTIMODUlE, 
Mag.cha"is. 
Micromainframe, 
Micromap. 
MULTI 
BUS, 
Multichannel, 
Plug-A-Bubble, 
PROMPT. 
Promware, 
RMXl80. 
System 2000, UPI. and the combination 
of leS, iRMX, iSBC. iSBX, ICE. MeS. 
or UPlarn:t. 
numerical 
sultix.lntel 
Corporation 
Assumes No Responsibility 
tor the use 


of Any Circuitry 
Other 
Than 
Circuitry 
Embodied 
in an Intel Product. 
No Other 
Patent 
lk:enses 
are implied. 
@INTElCORPORATION, 
1982. 
ORDER 
NUMBER: 
121707-001 


SUBMITTAL 
REQUIREMENTS 


Programs 
submitted 
for Insite 
review must follow 
the guidelines 
listed 
below: 


Programs must be written 
in a language capable of compilation 
and assembly 
by the currently-supported 


version 
of an Intel standard 
compiler/assembler. 
Accepted 
languages 
are documented 
in the following 


manuals 
available 
through 
Intel's 
Literature 
Department. 


- 
BASIC-80 Reference 
Manual, Order No. 400710 


- 
iCIS-COBOL 
Language 
Reference 
Manual, Order No. 409115 


- 
FORTRAN·80 
Programminy 
Manual, Order No. 400625 


- 
FORTRAN-86 User's Guide, Order No. 400645 


- 
Pascal·80 User's Guide, Order No.400660 


- 
Pascal·86 User's Guide, Order No. 400680 


- 
PUM-80 Programming 
Manual, Order No. 401700 


- 
PUM·86 Programming 
Manual, Order No. 402300 


- 
MCS-48 and UPI-41A Assembly 
Language 
Manual, Order No. 305000 


- 
MCS·86 Macro Assembly 
Language 
Reference 
Manual, Order No. 402105 


- 
8080/8085 Assembly 
Language 
Programming 
Manual, Order No. 401100 


- 
8086/8087/8088 Macro Assembly 
Language 
Reference 
Manual for 80/85 Based Development 
System, 
9rder 
No. 402165 


- 
8086/8087/8088 Macro Assembly 
Language Reference 
Manual for 80/86 Based Development 
System, 


Order No. 402157 


- 
8089 Assembly 
Language 
Reference 
Manual, Order No. 305000 


- 
Microsoft· 
BASIC Compiler 
Reference 
Manual, Order No. 121805 


- 
Microsoft· 
BASIC·80 Reference 
Manual, Order No. 121806 


- 
Microsoft· 
BASIC Reference 
Book, Order No. 121857 


- 
Microsoft· 
FORTRAN-80 Reference 
Manual, Order No. 121798 


- 
Microsoft· 
FORTRAN-80 User's Manual, Order No. 121799 


- 
Microsoft* 
M/Sort Reference 
Manual, Order No. 121809 


- 
Microsoft* 
Utility 
Software 
Manual, Order No. 121797 


A well·documented 
source 
code furnished 
on an ISIS-formatted 
diskette, 
CP/M·-formatted 
diskette, 


or ASCII·coded 
paper tape. 


A source 
listing 
of the program 
must be included. 
This must be the output 
listing 
of a compilation 
or an 


assembly. 
No consideration 
will be given to incomplete 
programs 
or duplications 
of programs 
already in 
the Library. 


A demonstration 
program which 
assures 
the validity 
of the contributed 
program 
must be included. 
This 
must show the accurate 
operation 
of the program. 


Licensed 
software 
or copyrighted 
material 
must 
be accompanied 
by a written 
release 
from the appro· 


priate, authorized 
person . 


• Microsoft is a trademark of Microsoft, Inc. 


·CP/M is a registered trademark of Digital Research, Inc. 


INSITE™ USER'S PROGRAM 
LIBRARY 
SUBMITTAL FORM 


Program 
Title 


Required 
Hardware 


Required 
Software 


Input 
Parameters 


Output 
Results 


D 8048 
D 
808018085 
D 
80861808718088 
D 
Other 


Indicate 
the Microcomputer 
Development 
System series 
model the program 
was 
created 
on by checking 
the appropriate 
box, and identify 
other Microcomputer 
Development 
System series 
models 
the program 
may be compatible 
with. 


Registers Modified: 
Programmer: 


RAM Required: 
Company: 


ROM Required: 
Address: 


Maximum Subroutine Nesting Leyel: 
City: 


Assembler/Complier Used: 
State: 


Programming Language: 
Telephone: 


ACKNOWLEDGEMENT AND AGREEMENT 


To the best of my knowledge, 
I have the right 10contribute 
thIS program material 
without 
breaching 
any oblrgation 
concernIng 
nondIsclosure 


of propnetary 
or confidential 
information 
01 other 
persons 
or organtzatlons. 
I am contributIng 
thiS program 
material 
on a nonconlidenlial 
nonobligatory 
basis 10 the InSlle User's LIbrary lor inclusIon 
In jts program 
library, and I agree that the Library may use, duplicate, 
modify, 


publiSh, and seilihe 
program material Without obligatIon 
or liability 
01any "md. The Insite User's library 
may publish 
my name and address, as 
the contributor, 
to lacihtate 
user inquiries 
perlaimng 
10 thIS program 
malenal 


SIgnature 
Date 


D 
CHECK/MONEY 
ORDER 


D PURCHASE 
ORDER 


D 
PROGRAM 
SUBMITIAL 


NORTH 
AMERICA 


Intel Corporation 
3065 Bowers Avenue 
Santa Clara, California 
95051 
ATTN: Insite User's Program Library 
Telephone: 408·987·8080 


THE ORIENT 
Intel Japan K.K. 
5-6 Tohkohdai, Toyosato·cho, 
Tsukuba·gun, Ibaraki, 300-26, Japan 
ATTN: Insite User's Program Library 
Telephone: 029747·8511 


Intel Corporation 
S.A.R.L. 


5 Place de la Balance 
Silic 223 
94528 Rungis Cedex, France 
ATTN: Insite User's Program Library 
Telephone: 
0687·22·21 


EUROPE 
Intel Semiconductor 
GmbH 
Seidlstrasse 
27 
8000 Muenchen 2 
West Germany 
ATTN: Insite User's Program Library 
Telephone: 089·5389·1 


Intel Corporation 
(U.K.) ltd. 


Pipers Way 
Swindon SN3 LRJ 
Wiltshire, 
England 
ATTN: Insile User's Program Library 
Telephone: 
0793·488·388 
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DIGITAL RESEARCH INC. 
CP/M* 2.2 OPERATING SYSTEM 


• High-performance, single-console 
operating system 


• Simple, reliable file system matched to 
microcomputer resources 


• Table-driven architecture allows field 
reconfiguration to match a wide variety 
of disk capacities and needs 


• Extensive documentation covers all 
facts of CP/M applications 


• 
More than 1,000 commercially available 
compatible software products 


• General-purpose subroutines and 
table-driven data-access algorithms 
provide a truly universal data 
management system 


• Upward compatibility from all previous 


versions 


CP/M 2.2 is a monitor control program for microcomputer 
system and application 
uses on InteI8080/8085-based 


microcomputer 
(see the CP/M-86 
* Operating 
System 
data sheet for information 
on CP/M for Intel 8086/8088- 


based systems). 
CP/M provides 
a general 
environment 
for program 
execution, 
construction, 
storage, 
and 


editing, 
along with the program 
assembly and check-out 
facilities. 


The CP/M monitor provides rapid access to programs through 
a comprehensive 
file management 
package. The 


file subsystem supports 
a named file structure, 
allowing 
dynamic allocation 
of file space as well as sequential 


and random file access. Using this system, a large number of distinct 
programs 
can be stored in both source- 


and machine-executable 
form. 


CP/M also supports 
a powerful 
context editor, Intel-compatible 
assembler, and debugger 
subsystems. Nearly all 


personal software 
programs 
can be bought configured 
to run under CP/M, several of which are available from 


Intel. 


-Provides 
primitive 
operations 
for access to disk 
drives 
and 
interface 
to 
standard 
peripherals 
(teletype, 
CRT, paper tape reader/punch, 
bubble 
memory, and user-defined 
peripherals) 


-Allows 
user modification 
for tailoring 
to a particu- 


lar hardware environment 


-Provides 
disk management 
for one to sixteen disk 
drives containing 
independent 
file directories 


-Implements 
disk 
allocation 
strategies 
for 
fully 
dynamic 
file 
construction 
and 
minimization 
of 
head movement across the disk 


-Uses 
less than 4K of memory 
allowing 
plenty 
of 


memory space for applications 
programs 


-Uses 
less than 4K of memory 


-Makes 
programs 
transportable 
from 
system 
to 


system 


-Entry 
points 
include 
the 
following 
primitive 


operations 
which 
can 
be 
programmatically 


accessed: 


OPEN 


CLOSE 


RENAME 


READ 


WRITE 


SELECT 


Look for a particular 
disk file by 


name 


Open a file for further 
operations 


Close a file after processing 


Change the name of a particular 
file 


Read a record from a particular 
file 


Write a record to a particular 
file 


Select a particular 
disk drive for 


further 
operations 


inter 
DIGITAL RESEARCH, INC. 
CP/M 2.2 


-Provides 
primary 
user interface 
by reading 
and 


interpreting 
commands 
entered 
through 
the 


console 


-Loads 
and transfers control to transient programs, 
such as assemblers, editors, and debuggers 


-PrOcesses 
built-in standard commands 
including: 


ERA 
Erase specified 
files 


DIR 
List file names in the directory 


REN 
Rename the specified 
file 


SAVE 
Save memory contents 
in a file 


TYPE 
Display 
the contents 
of a file on 


the console 


-Holds 
programs 
which 
are loaded from the disk 


under command 
of the CCP 


-Programs 
created under CP/M can be checked out 


by loading 
and 
executing 
these 
programs 
in 


the TPA 


-User 
programs, 
loaded into the TPA, may use the 


CCP area for the program's 
data area 


-Transient 
commands 
are specified 
in the same 


manner as built-in commands 


-Additional 
commands can be easily defined by the 


user 


-Defined 
transient 
commands 
include: 


PIP 
Peripheral 
Interchange 
Program 
-implements 
the basic media transfer 


operations 
necessary to load, print, 


punch, copy, and combine disk files; 
PIP also performs various 
reformatting 
and concatenation 


functions. 
Formatting 
options include 


parity-bit 
removal, case conversion, 
Intel hex file validation, 
subfile 


extraction. 
tab expansion, line number 


generation. 
and pagination 


ED 
Text Editor-allows 
creation and 


modification 
of ASCII files using 


extensive context editing commands: 
string substitution, 
string search, 


insert, delete and block move; ED 
allows text to be located by context. 
line number, or relative position with a 
macro command for making extensive 
text changes with a single command 
line 


ASM 
Fast 8080 Assembler-uses 
standard 


Intel mnemonics and pseudo 
operations 
with free-format 
input, and 


conditional 
assembly features 


DDT 
Dynamic Debugging Tool-contains 
an integral assembler/disassembler 
module that lets the user patch and 
display memory in either assembler 
mnemonic or hexadecimal 
form and 


trace program execution with full 
register and status display; 
instructions 
can be executed between 


breakpoints 
in real-time, or run fully 


monitored, one instruction 
at a time 


SUBMIT 
Allows a group of CP/M commands to 
be batched together 
and submitted 
to 


the operating 
system by a single 
' 


command 


STAT 
Lists the number of bytes of storage 
remaining 
on the currently 
logged 


disks, provides statistical 
information 


about particular 
files, and displays or 


alters device assignments 


LOAD 
Converts Intel hex format to absolute 
binary, ready for direct load and 
execution 
in the CP/M environment 


SYSGEN 
Creates new CP/M system disks for 
back-up purposes 


MOVCPM 
Provides regeneration 
of CP/M 


systems for various memory 
configurations 
and works in 


conjunction 
with SYSGEN to provide 


additional 
copies of CP/M 


-Easy 
implementation 
on any computer 
configura- 


tion which 
uses an Intel 8080/8085 Central 
Pro- 


cessing Unit (see the CP/M-86 data sheet for CP/M 
applications 
on the iAPX86 CPU) 


-iPDS 
version supports 
bubble 
memory option 
as 


an additional 
diskette 
drive. Also allows diskette 


duplication 
with a single drive 


-Extensive 
selection of CP/M-compatible 
programs 


allows production 
and support 
of a comprehen- 


sive software 
package at low cost 


-Field 
programmability 
for special-purpose 
operat- 


ing system requirements 


-Upward 
compatibility 
from 
previous 
versions 
of 


CP/M release 1 


intJ 
DIGITAL RESEARCH, INC. 
CP/M 2.2 


-Provides 
field specification 
of one tosixteen 
logi- 
cal drives, each containing 
up to eight megabytes 


-Files 
may contain 
up to 65,536 records of 128 bytes 
each but may not exceed the size of any single disk 


-Each 
disk 
is designed 
for 64 distinct 
files-more 
directory 
entries 
may be allocated 
if necessary 


-Individual 
users are physically 
separated 
by user 
numbers, 
with 
facilities 
for 
file 
copy 
operations 
from one user area to another 


-Relative-record 
random-access 
functkms 
provide 
direct 
access 
to any of the 65,536 
records 
of an 
eight-megabyte 
file 


-Model 
800 with 720 kit 


-OS 
235 kit or MDS 225 with 720 kit (integral 
drive 
supported 
except 
as system 
boot device) 


-iPDS 
Personal 
Development 
System 
Optional: 


RAM up to 64K 


-Additional 
floppy 
disk drives 


-Single 
density 
via 201 controller 


-Bubble 
memory 
and optional 
Shugart 
460 5Y4" 
disk drive for iPDS 


Title 


CP/M 2.2 documentation 
consisting 
of 7 manuals: 


An Introduction 
to CP/M Features 
and Facilities 
CP/M 2.2 User's Guide 
CP/M Assembler (ASM) User's 
Guide 
CP/M Dynamic Debugging Tool 
(DOT) User's Guide 
ED: A Context Editor for the CP/M 
Disk System User's Manual 
CP/M 2 Interface Guide 
CP/M 2 Alteration Guide 


(Specify 
by Alpha Character 
when ordering.) 


A-single 
density 
(IBM 3740/1 compatible) 


B-double 
density 


F-double-sided, 
double 
density 
5W' floppy 
(iPDS 
format) 


Order Code 
Product Description 


See Price 
List CP/M (Control Program 
for 
Microcomputers) 
is a disk-based 
operating system for the Intel 
8080/8085-based systems. CP/M 
provides a general environment 
for 
program development, test, execution 
and storage. CP/M storage is available 
via a comprehensive, named-file 
structure supporting 
both sequential 


and random access. CP/M support 
tools include a Text Editor, a 
debugger, and an 8080/8085 
assembler. 


Intel offers several levels of support 
for this product, 
depending 
on the system configuration 
in which 
it is used. 


Please consult 
the price 
list for a detailed 
description 
of the support 
options 
available. 


An Intel Software License required. 
·CP/M is a registered trademark of Digital Research, Inc. 
·CP/M-86, MP/M, CP/NET and MP/NET are trademarks of Digital Research, Inc. 
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DIGITAL RESEARCH INC. 
CP/M-86* OPERATING SYSTEM 


• High-performance, single-user 


operating system for 16-bit computers 
based on Intel's iAPX-86 (8086) and 
compatible iAPX-88 (8088) 
microprocessors 


• CP/M-86 files are completely 


compatible with versions of CP/M* used 
with Intel 8-bit 8080- and 8085-based 
microcomputer systems 


• Supports up to 16 logical drives, each 


containing up to eight megabytes for a 
total of 128 megabytes of on-line 
storage 


• CP/M-86 manages up to 1 Mbyte of on- 


line RAM storage for full support of 
programs as large and as powerful as 
those found on minicomputers 


• The standard CP/M-86 package 


includes an assembler, an interactive 
debugger, and additional utilities for 
complete program development 


CP/M-86 is a single-user 
operating 
system designed especially for 16-bit computers 
based on the Intel iAPX-86 
(8086) and compatible 
iAPX-88 (8088) microprocessors. 
The system fully utilizes the one megabyte (1,048,576 
bytes) of main memory available for application 
programs. 


CP/M-86 occupies 
only 11K of memory with a floppy disk-based 
I/O System occupying 
about 1K, depending 
on 
the number 
of peripherals 
supported. 
The remainder 
of the 8086/8088 address space may be defined 
by the 
user. Flexibility 
is provided by the system's ability to reside anywhere in memory, and it can be relocated 
by the 
user without 
changing 
the operating 
system. 


Because CP/M-86 files are completely 
compatible 
with CP/M for Intel 8-bit microprocessors, 
there is an easy 
upgrade 
of existing 
CP/M applications 
software 
to 16-bit iAPX-86 (8086)-based systems. 


Major 
features 
of the 
CP/M-86 
operating 
system 


include: 


Based on a proven, modular 
design, the system in- 


cludes the: 


-CCP: 
Console Command 
Processor 


The CCP is the human interface 
to the operating 


system and performs 
decoding 
and execution 
of 
user commands 


-BOOS: 
Basic Disk Operating 
System 


The BOOS is the logical, 
invariant 
portion 
of the 


operating 
system; it supports 
a named file system 


with a maximum of 16 logical drives, containing 
up 


to 
8 megabytes 
each 
for 
a potential 
of 
128 


megabytes 
of on-line storage 


-BIOS: 
Basic Input/Output 
System 
The physical variant 
portion 
of the operating 
sys- 


tem, 
BIOS 
contains 
the 
system-dependent 
in- 


put/output 
device handlers 


CP/M-86 files are completely 
compatible 
with CP/M 


for 808D- 
and 8085-based 
microcomputer 
systems. 


This 
simplifies 
the 
conversions 
of 
software 


developed 
under CP/M and allows full advantage 
of 


16-bit 8086-based systems. 


The 
user 
will 
notice 
no significant 
difference 
be- 


tween CP/M and CP/M-86. Commands 
such as OIR, 


TYPE, 
REN, ERA, PIp, ED, and 
STAT respond 
the 


same way in both systems. 
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CP/M-86 uses the 8086 registers 
corresponding 
to 


8080 registers for system call and return parameters 
to further 
simplify 
software transport. 
The execution 


environment 
in CP/M-86 allows code and data seg- 
ments to overlap, 
making 
the mixture 
of code and 


data that often appears in 8-bit applications 
accept- 
able to the 8086. 


CP/M-86 can support 
up to 16 logical 
drives, each 


containing 
up to eight megabytes, for a maximum 
of 


128 megabytes 
of on-line 
storage. Anyone 
file can 


reach the full drive size, with space dynamically 
al- 


located and released. Each device has a directory 
of 


file control 
blocks that map the physical location 
of 


each file on the disk. 
Disk definition 
tables 
in the 


BIOS translate 
this logical 
drive, directory, 
and file 


structure 
to the physical characteristics 
of the disk. 


This file system is identical to the file system of CP/M. 


CP/M-86 
can 
reside 
anywhere 
in memory 
and 
is 


easily located to minimize 
dependence 
on absolute 


addresses. Multiple 
programs 
may reside in memory 


simultaneously. 
Also, a transient 
program 
may load 


additional 
programs for execution under its own con- 


trol. 
Up to a total 
of 8 programs 
may use non- 


contiguous 
memory 
areas 
which 
are 
managed 


through 
a user-defined 
memory configuration 
table. 


The distribution 
version of CP/M-86 is set up for oper- 
ation with 
the Intel iSBC 86/12A and an Intel 204 


diskette 
controller. 
All hardware 
dependencies 
are, 
however, concentrated 
in subroutines 
which are col- 


lectively referred to as the Basic I/O System, or BIOS. 
A CP/M-86 
system 
implementor 
can 
modify 
these 


subroutines 
to tailor CP/M-86 to fit nearly any 8086 or 


8088 operating 
environment. 


To simplify 
the 
preparation 
of a custom 
BIOS, a 


source 
listing 
of a working 
BIOS, a skeleton 
for a 


custom module, and cross-development 
utilities are 


supplied. 
The cross-development 
programs 
allow 


development 
of custom BIOS and CP/M-86 applica- 


tions software 
on an 8-bit CP/M system. 


For users who have the iSBC 86/12 hardware 
co'n- 


figuration, 
there 
is an optional 
PROM Loader. The 


firmware 
brings the CP/M-86 loader into the system 


and sets up the hardware to initialize 
CP/M·86. 


PIP 
The Peripheral 
Interchange 
Program 
provides 
file 
transfer between devices and disl< files and performs 
various 
reformatting 
and concat'3nation 
functions. 


Formatting 
options 
include 
parity-bit 
removal, case 


conversion, 
Intel "hex" file validation, 
subfile extrac- 


tion, 
tab 
expansion, 
line 
number 
generation, 
and 


pagination. 


ED 
The CP/M-86 Text Editor allows creation 
and modifi- 


cation 
of ASCII files 
using 
extensive 
commands: 


string 
substitution, 
string 
search, insert and delete. 


ED allows text to be located by context, line number, 
or relative position 
with a macro command 
for mak- 


ing extensive text changes 
with a single 
command 


line. 


ASM-86 
ASM-86, the CP/M-86 Assembler 
is an 8086 assem- 


bler using standard 
Intel mnemonics. 
It also allows 


users to define 
unique 
instructions 
with the code- 


macro facility. ASM-86 is supplied 
in two forms: 
an 


8086 cross assembler 
designed 
to run under CP/M 
(an 8-bit system), and an 8086 assembler designed to 
run under CP/M-86. 


DDT-86 
The CP/M-86 
Dynamic 
Debugging 
Tool allows 
the 


user to test and debug 
programs. interactively 
in a 


CP/M·86 
environment. 
The 
command 
set allows 


users to trace program 
execution 
with full register 


and status display. DDT-86 contains 
an integral 
as- 


sembler/disassembler 
module that lets users patch 


and display memory in assembler 
mnemonic 
form. 


SUBMIT 
Allows a group of CP/M-86 commands 
to be batched 


together 
and submitted 
to the operating 
system by a 


single command. 


STAT 
Lists the number 
of bytes of storage 
remaining 
on 


the currently 
logged disks, provides statistical 
infor- 


mation 
about particular 
files, and displays or alters 


device assignments. 


GENCMD 
and LMCMD 
GENCMD and LMCMD 
are used to produce 
CMD 
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memory 
image 
files 
suitable 
for execution 
under 
CP/M-86. The GENCMD utility 
processes 
Intel files, 
which may be produced 
either by Digital Research's 
ASM-86 or by Intel's OH86 utility. LMCMD processes 
Intel L-module files resulting from the standard 
Intel 
LOC86 Object 
Code 
Relocator 
Utility. These com- 
mands allow generation 
of new utilities. 


-Designed 
especially 
for 
full 
advantage 
of Intel 
iAPX-86/12A (8086)-based computer 
systems 


-Complete 
compatibility 
with versions of CP/M for 
Intel 
8080/808S-based 
microcomputer 
systems 
makes it easy to upgrade 
existing 
CP/M applica- 
tions 
software 
to preserve 
software 
investment 
(see the CP/M 
Operating 
System 
data sheet for 
additional 
CP/M benefits) 


-Cross-development 
tools, 
including 
the ASM-86 
assembler and the GENCMD utility, can reside on a 
8080/808S-based CP/M system; with these tools, 
the programmer 
can assemble a custom BIOS pro- 


. gram and generate a loadable object file that runs 
on the target system 


-Proven 
modular design occupies 
a small amount 
of memory to give maximum 
user-defined 
space 


for 
application 
programs 
in the 
available 
one- 
megabyte main memory. 


--'-Allows up to 128 megabytes 
of on-line 
magnetic 
storage 


-CP/M-86 
manages up to 1 Mbyte of on-line 
RAM 
storage for full support 
of programs 
as large and 
as powerful 
as those found on minicomputers 


-Allows 
multiple 
programs 
in memory for transient 
program 
execution; 
multiple 
programs 
may use 
non-contiguous 
memory 
areas 
for 
application 
programs 


-ASM-86 
and DDT-86 provide 
the basic tools 
for 
assembly 
language 
development 
and 
program 
debugging 
using the iAPX-86/12A 
(8086) micro- 
processor 


-CP/M-86 
is a complete system including 
the oper- 
ating 
system 
and 
development 
tools; 
a 
comprehensive 
set of manuals describes 
system 
operation, 
customization, 
interfacing 
of applica- 
tions programs, 
listings of sample programs, 
and 
operation 
of the assembler, debugger, and editor 


-The 
CP/M-86 package includes full documentation 
for the product; 
documentation 
is also available 
separately; a CP/M-86 PROM loader is available for 
the Intel Single-Board 
Computer 


Hardware 
Required 


-iSBC 
86/12A 
-iSBC204 
-CRT 


Optional: 


-up 
to 1 megabyte RAM 
-up 
to 16 disk drives (8 megabytes each) 


Description 


CP/M-86 
system, 
program 
and 
user's 
gu ides 


(Specify by Alpha Character when ordering.) 


A- 
Single Density (Intellec compatible, 
IBM 3740/1 format) 


Order Code 


SD12CPM86A 
CPM-861.0 


Description 


CP/M-86 
is a single-user 
operating 
system 
for the Intel 
8086 and 8088 
microprocessors. 
CP/M-86 
is modular 
in design, 
occupies 
a small 
amount 
of memory, 
and 
is completely 
compatible 
with 
earlier 
CP/M 
2.2 for 
8-bit 
microprocessors. 
As a part 
of 
the CP/M-86 
package, 
Digital 
Research 
provides 
an assembler, 


interactive 
debugging 
tool, 
and other 
development 
utilities 
to allow 
users 
to 
copy 
files, 
edit 
files 
and generate 
memory 
image 
files. 


Intel offers several levels of support for this product, depending 
on the system configuration 
in which it is used. 
Please consult the price list for a detailed description 
of the support 
options 
available. 


An Intel Software 
License required. 
·CP/M is a registered 
trademark 
of Digital Research, Inc. 
·CP/M-B6 is a trademark 
of Digital Research, Inc. 


MICROSOFT*, INC. MACRO-SO UTILITY 
SOFTWARE PACKAGE 


• Includes the MACRO-SO macro 


assembler, LINK-SOlinking loader, and 
CREF-SOcross-reference facility 


• Supports a complete, Intel-standard 


MACRO facility, including IRP, IRPC, 
REPEAT, local variables, and EXITM 


• Supports conditional assembly, 


including testing of assembly pass, 
symbol definition, and parameters to 
MACROs 


• Code is assembled in relocatable 


modules for easy manipulation by the 
LINK-SOlinking loader 


• Assembly rate of over 1000 lines per 


minute 


• 
Provides "big computer" assembler 
features without sacrificing speed or 
memory space 


• Provides a complete set of listing 


controls 


• 
LINK-SOloads relocatable modules at 
user-specified locations 


• CREF-SOcross-reference facility 


alphabetizes program variables and 
shows where each is defined and 
referenced 


The Microsoft 
Utility 
Software 
Package 
is a complete 
system for developing 
assembly 
language 
programs, 
routines, and subroutines. 
The Utility Software 
Package includes the MACRO-BO macro assembler, the L1NK-BO 
linking 
loader, and the CREF-BO cross-reference 
facility. The CP/M' version 
also includes 
the L1B-BOLibrary 
Manager. 


The Utility Software Package is supplied with all Microsoft 
compilers 
to provide assembly language subroutine 
support 
to main 
programs 
in the 
high-level 
programming 
languages. 
The 
L1NK-BOlinking 
loader 
is used 
by all Microsoft 
compilers 
for linking 
and loading 
compiled 
relocatable 
modules. 
Thus, L1NK-BOallows 
the 
programmer 
to link together 
relocatable 
modules from different 
Microsoft 
languages. 


MACRO-BO incorporates 
almost 
all "big 
computer" 
assembler 
features 
without 
sacrificing 
speed 
or 


memory space. The assembler supports 
a complete, 
Intel-standard 
macro 
facility, 
including 
IRP, IRPC, 
REPEAT, local variables, 
and EXITM. Macro 
names 


take 
precedence 
over 
instruction 
mnemonics 
and 


pseudo operations. 
Nesting of macros is limited only 


by memory. 
Code 
is assembled 
in 
relocatable 


modules that are easily manipulated 
with the flexible 


linking 
loader. 
Conditional 
assembly 
capability 
is 


greatly enhanced 
by an expanded 
set of conditional 


pseudo operations 
that include 
testing 
of assembly 


pass, symbol 
definition, 
and parameters 
to macros. 


Conditionals 
may be nested up to 255 levels. 


More MACRO-BO features: 


-Comment 
blocks 


-Variable 
input radix from base 2 to base 16 


-Octal 
or hex listings 


-INCLUDE 
statement assembles an alternate 


_ source file into the current program 


-PRINTX 
statement for printing 
assembly or 


diagnostic 
messages 


-PHASE/DEPHASE 
statements allow code to 


reside in one area of memory but execute in 
another 


-Complete 
set of listing controls 


With 
L1NK-BO, any 
number 
of programs 
may 
be 


loaded with one command, 
relocatable 
modules may 


be loaded 
in user-specified 
locations, 
and external 


references 
between 
modules 
are resolved automati- 
cally by the loader. The loader also performs 
library 


searches 
for 
system 
subroutines 
and generates 
a 


memory load map showing the locations 
of the main 


program 
and subroutines. 


The Cross-Reference 
Facility that is included with the 
Utility 
Software 
Package 
supplies 
a convenient 
al- 
phabetic 
list of all program 
variable 
names, along 
with 
line numbers 
where 
they 
are referenced 
and 
defined. 


MACRO-BO resides 
in approximately 
19K bytes of 


memory. L1NK-BOresides in approximately 
14K bytes 


of memory. 
CREF-BO requires 
about 
6K bytes. The 


MACRo-BO 
Utility 
Software 
Package 
is compatible 


with the CP/M' 
operating 
system. 


InteliecilP 
Microcomputer 
Development 
System 


-Model 
BOOor 
-Series 
II 
-iPDS 
(Personal 
Development 
System) 


-minimum 
of 
'1 diskette 
drive 


CP/M Operating 
System or MP/M-W Operating 


System. 


One 
copy 
of each 
manual 
is supplied 
with 
the 
software 
package. 


Description 


Microsoft 
Utility 
Software 
Manual 


(Specify 
by Alpha Character 
when ordering.) 


A-Single 
Density (InteliecilP 
compatible, 


IBM 3740/1 format) 


B-Double 
Density (InteliecilP 
compatible, 


M2FM format) 


F-Double-sided, 
Double Density 5%" 


Floppy (iPDS format) 


Order Code 


SD106CPMBOA 


SD106CPMBOB 


SD106CPMBOF 


Description 


Microsoft 
MACRO-BO Utility 
Software 
Package, CP/M version 
(Single-Density 
Diskette) 


Microsoft 
MACRO-BO Utility 
Software 
Package, CP/M version 
(Double-Density 
Diskette) 


Microsoft 
MACRO-BO Utility 
Software 
Package, CP/M version 
(iPDS Format) 


Intel offers several levels of support for this product, 
depending 
on the system configuration 
in which it is used. 


Please consult 
the price list for a detailed 
description 
of the support 
options 
available. 


An Intel Software License required. 
'Microsoft 
is a trademark of Microsoft, Inc. 
"CP/M is a registered trademark of Digital Research. Inc. 
"MP/M-II is a trademark of Digital Research, Inc. 


MICROSOFT*, INC. BASIC-80 INTERPRETER 
SOFTWARE PACKAGE 


• Compatible 
with other Microsoft 
BASIC 
compilers 
and interpreters 


• Sophisticated 
string handling 
and 
structured 
programming 
features 
for 
applications 
development 


• Direct transfer 
of BASIC programs to 
the 8085, 8086 and 8088 


• Random and sequential 
file 
manipulation 
where random file record 
length is user-definable 


• 
Read or write memory location 
capabilities 


• 
Meets the requirements 
for the ANSI 
subset standard 
for BASIC, and 
supports 
many enhancements 


• Extensive text editing features 
built-in 


• Automatic 
line number generation 
and 
renumbering 


• Supports assembly 
language 
subroutine 
calls 


• Trace facilities 
for easier debugging 


BASIC Release 5.0 from 
Microsoft 
is an extensive 
implementation 
of BASIC. Microsoft 
BASIC gives users what 


they 
want 
from 
a BASIC-ease 
of use plus 
the 
features 
that 
are comparable 
to a minicomputer 
or large 
mainframe. 


BASIC-SO meets the requirements 
for the ANSI subset standard 
for BASIC, as set forth 
in document 
BSRX3.6o- 


1975. It supports 
many unique 
features 
rarely found 
in other 
BASICs. 


-Four 
variable types: Integer (-3276S, 
+32767), 
String 
(up to 255 characters), 
Single-Precision 
Floating 
Point (7 digits), 
Double-Precision 
Floating 
Point (16 digits). 


- 
Trace facilities 
(TRON/TROFF) 
for easier 
debugging. 


-Error 
trapping 
using the ON ERROR GOTO 
statement. 


-PEEK 
and POKE statements 
to read or write any 
memory 
location. 


-Automatic 
line number 
generation 
and 
renumbering, 
including 
reference 
line numbers. 


-Boolean 
operators 
OR, AND, NOT, XOR, EQV, 
IMP. 


-Formatted 
output 
using the PRINT USING facility, 


including 
asterisk 
fill, floating 
dollar 
sign, 
scientific 
notation, 
trailing 
sign, and comma 
insertion. 


-Direct 
access to I/O ports with the INP and OUT 
functions. 


-Extensive 
program 
editing 
facilities 
via EDIT 
command 
and EDIT mode subcommands. 


-Assembly 
language 
subroutine 
calls (up to 10 per 
program) 
are supported. 


-IF/THEN/ELSE 
and nested IF/THEN/ELSE 
constructs. 


-Supports 
variable-length 
random 
and sequential 
disk files with a complete 
set of file manipulation 
statements: 
OPEN, CLOSE, GET, PUT, Kill, 


NAME, MERGE. 
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BASIC-SOCommands, Statements, 
Functions 


AUTO 
LIST 
NULL 
TROFF 
CLEAR 
LOAD 


RENUM 
WIDTH 
CONT 
MERGE 
RUN 
DELETE 


NAME 
SAVE 
EDIT 
NEW 
TRON 


Program Statements 


CALL 
RANDOMIZE 
GOSUB 
COMMON 


END 
DEF FN 


GOTO 
ERROR 


STOP 
POKE 


WHILE/ 
RESUME 


WEND 
SWAP 


CHAIN 
DEFDBL 


DEF USR 
DEFSTR 


LET 
DEFSNG 


REM 
DEFINT 


RETURN 
WAIT 
ON GOSUB 
DIM 
FOR/NEXT/ 


STEP 
IF/THEN/ 


ELSE 
ON ERROR 
GOTO 
OPTION BASE 


Input/Output Statements and Functions 


CLOSE 
GET 
NAME 


KILL 
POS 
PUT 


OUT 
FIELD 
EOF 


RESTORE 
LSET/RSET 
SPC 


READ 
PRINT 
INKEY$ 


TAB 
USING 
INPUT 


DATA 
LOC 
OPEN 


LINE 
MKI$ 
CVD 


INPUT 
MKS$ 
CVI 


PRINT 
MKD$ 
CVS 


WRITE 
LliST 


LPRINT 
LPOS 


ABS 
SIN 
INT 
CDBL 
SGN 
CSNG 
ATN 
CINT 
EXP 
SQR 


LOG 
FIX 
COS 
RND 
TAN 


String Functions 


ASC 
STR$ 
LEN 
HEX$ 
STRING$ 
OCT$ 
CHR$ 
VAL 


.LEFT$ 


INSTR 
RIGHT$ 
MID$ 
SPACE$ 


XOR 
NOT 
EQV 
MOD 
IMP 
OR 
AND 


<= 
+ 
<> 
\ 
>= 


Special Functions 


ERL 
ERR 
USR 
FRE 
VARPTR 
PEEK 


The 
standard 
disk 
version 
of 
Microsoft 
BASIC-80 


occupies 
24K bytes of memory. 
Microsoft 
BASIC-80 


Interpreter 
is compatible 
with 
Intel's 
ISIS operating 


system 
or CP/M- 
operating 
system. 


Intellec 
Microcomputer 
Development 
System 


-Model 
800 or 
-Series 
II 
-iPDS 
(Personal 
Development 
System) 
-minimum 
of 1 diskette 
drive 


One 
copy 
of 
each 
manual 
is supplied 
with 
the 


software 
package. 


Description 


BASic-aD Reference Manual 
BASIC Reference Book 
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(Specify 
by Alpha 
Character 
when ordering.) 


A-Single 
Density 
(Intellec 
compatible, 
IBM 3740/1 format) 


B-Double 
Density 
(Intellec 
compatible, 
M2FM format) 


F-Double-sided, 
Double 
Density 
5W' Floppy 
(iPDS format) 


Order Code 


SD102CPMSOA 


Description 


Microsoft 
BASIC-80 
Interpreter 
Software 
Package, 
CP/M version 
(Single-Density 


Diskette) 


Microsoft 
BASIC-80 
Interpreter 
Software 
Package, 
CP/M version 
(Double-Density 


Diskette) 


Microsoft 
BASIC-SO Interpreter 
Software 
Package, 
CP/M version 
(Double-Sided, 


Double 
Density 
5%" Floppy) 
iPDS format 


Microsoft 
BASIC-80 
Interpreter 
Software 
Package, 
ISIS version 
(Double-Sided, 


Double 
Density 
5%" Floppy) 
iPDS format 


Intel offers 
several levels of support 
for this product, 
depending 
on the system 
configuration 
in which 
it is 


used. 
Please 
consult 
the 
price 
list 
for 
a detailed 


description 
of the support 
options 
available. 


An Intel Software 
License required. 


·Microsoft 
is a trademark 
of Microsoft, 
Inc. 
·CP/M is a registered trademark 
of Digital Research, Inc. 
·MP/M-II is a trademark 
of Digital Research, Inc. 


MICROSOFT*, INC. COBOL-80 
SOFTWARE PACKAGE 


• GSA validation at low-intermediate 
level implementation of ANSI 74 
requirements 


• Combines the most useful Level 1 and 
Level 2 ANSI 74 features, making it the 
most extensive implementation of 
COBOL for microcomputers 


• Interactive accept/display features 
allow direct interaction between data, 
program and operator 


• Highly efficient pseudo-code compiler 
produces compact, fast code 


• Complete utility software package, 
including macro assembler, linking 
loader, and MICROSOFT M/SORT 


• Tailorable screen-formatting facilities 
allow configuration to any intelligent 
terminal for menu and forms 
generation 


• COBOL offers four kinds of files for 
simplicity and speed in data retrieval 


COBOL has been the language of choice for commercial 
data processing 
for over two decades, and because of 
its established 
superiority, 
more 
useful 
business 
software 
has been written 
in COBOL 
than 
in any other 
language. That means quality, full-function 
packages, many written 
by the field's foremost experts, are available 
now. Existing 
systems for payroll, accounts 
receivable, 
general ledger, inventory, 
order entry, and forecasting 
can run under Microsoft 
COBOL-80. 


COBOL offers the flexibility 
that makes products 
adaptable, versatile, and available to thousands 
of microcom- 
puter 
users. COBOL-80 
not only 
retains 
the high-level 
features 
of standard 
COBOL, 
but also 
introduces 
superior 
interactive 
capabilities 
and user-oriented 
features which represent a major advance in the commercial 
use of COBOL. With COBOL-80, direct interaction 
between data, program, 
and operator 
becomes possible. The 
immediate 
acknowledgement 
or rejection 
of user-entered 
data facilitates 
equally 
immediate 
corrections 
and 
mod ifications. 


COBOL-SOANSI Standard 
and GSAValidated 


Because 
COBOL 
is so widely 
used, assurances 
of 
compatibility 
and 
portability 
are important 
to all 
users. The American 
National 
Standards 
Institute 
has established 
guidelines 
which provide a basis for 
making 
informed 
comparisons 
of different 
COBOL 
compilers. 
Elements of the COBOL language are al- 
located 
to twelve 
different 
functional 
processing 
modules, 
at two different 
levels. Microsoft 
COBOL 
combines 
the 
most 
useful 
Level 
1 and 
Level 
2 
features. 


The United States government, 
through 
the General 
Services 
Administration 
(GSA), tests COBOL 
com- 
pilers to validate their compatibility 
and their imple- 
mentation 
of 
the 
ANSI 
74 standard. 
Microsoft 
COBOL 
for 
the CP/M 
operating 
system 
has been 


validated 
by GSA as a low-intermediate 
implementa- 
tion of the ANSI 74 standard. 
Microsoft 
COBOL 
is 
approved 
tor federal 
government 
installations, 
plus 
you have assurance 
that Microsoft 
COBOL will per- 
form to specifications. 


COBOL-80 supports 
such special features 
as: 


Advanced verbs: 
STRING, UNSTRING, COMPUTE, SEARCH, 
PERFORM (VARYING/UNTIL) 
Abbreviated 
and compound 
conditions 
Sequential, 
Relative, and Indexed files 
ASCII, packed and binary data formats 
Runtime assignment 
of file names 
Full COPY facility 
Line Sequential 
files 
Trace style debugging 
COMP-3 data format 
Program CHAIN 
Program Segmentation 
Formatted 
screen ACCEPT/DISPLAY 
with a single command 
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COBOL's 
unique 
suitability 
to the business 
environ- 
ment is due in large part to the structuring 
capabili- 
ties 
built 
into 
the 
language. 
COBOL-80 
programs 


have 
a natural, 
logical 
organization 
which 
reflects 


the nature 
of commercial 
data. This efficient, 
clean, 
top-down 
design 
makes COBOL-80 
programs 
faster 
to write 
and easier 
to maintain 
than those written 
in 


other 
computer 
languages. 


OOOO-MAIN-LiNE. 


PERFORM 
1000-INITIALIZE. 


PERFORM 
2000-ENTER 
ORDER 


UNTIL END-SESSION. 
IF REPORT-REQUIRED 


PERFORM 
3000-PRINT 
SUMMARY. 


PERFORM 
4000-TERMINATE. 


CHAIN "MAINMENU". 


1OOO-INITIALIZE. 
DISPLAY SIGN-ON-SCREEN. 
ACCEPT 
SIGN-ON-SCREEN. 
PERFORM 
1100-CHECK-SECURITY-CODE. 
MOVE ZERO TO ORDER-COUNT 


ERROR-CODE. 
SESSION-TOTAL. 


The data in COBOL 
programs 
is arranged 
hierarchi- 


cally. Information 
is stored 
in a logical 
structure 
with 


direct 
interconnection 
between 
related 
pieces 
of 


data. (Note 
here how 
COBOL's 
PICTURE 
specifica- 
tion 
allows 
exact 
decimal 
arithmetic 
for 
precise 


representation 
of any dollar 
amount.) 


05 TRANSACTION 
10 TRAN-REF. 
10 TRAN-DATE. 


15TRAN-MM 
15 TRAN-DD 
15 TRAN-YY 
10 POST-DATE. 


15 POST-MM 
15 POST-DO 
15 POST-YY 
10 TRAN-AMOUNT 
10TRAN-AMOUNT 


PIC XX. 
PIC XX. 
PIC XX. 


PIC XX. 
PIC XX. 
PIC XX. 
PIC S9(8)V99. 
PICX(4). 


Once this structure 
has been coded 
it can be stored 


in a file and used in any program. 
Only one statement 


is needed 
to retrieve 
it: COpy 
TRANSDEF.COB. 


COBOL-80 
obviates 
the 
need to recode 
every 
pro- 
gram in a system when a single defin!tion 
is added or 


changed. 
Any 
chance 
of 
inconsistencies 
between 


programs 
is eliminated. 
At execution, 
each item in a 


COBOL-80 
data structure 
may be referenced 
individ- 


ually, or grouped 
items may be manipulated 
as easily. 


Processing 
code 
accesses 
the structure 
at any ap- 


propriate 
level: 


MOVE JOURNAL-TRAN 
TO TRANSACTION. 


MOVE CURRENT-DATE 
TO POST-DATE. 


IF TRANS-AMOUNT 
<0 
MOVE TRANSACTION 
TO CR-TRAN. 


ELSE 
MOVE TRANSACTION 
TO DB-TRAN. 


COBOL's 
move from the batch environment 
to online 


applications 
has 
brought 
a new 
emphasis 
to 
the 
interaction 
between 
the application 
and the terminal 


operator. 
COBOL-80 
provides 
a SCREEN 
SECTION 


for the definition 
of formatted 
screens. 
Special 
syn- 


tax is available 
for cursor 
positioning, 
protected 
and 


unprotected 
fields, 
highlighting, 
full 
and 
partial 


screen 
erase, and for defining 
connections 
between 
fields 
defined 
on 
the 
screen 
and 
data 
sourcel 


destination 
fields 
in WORKING-STORAGE. 
Data 


entry 
forms, 
menus, 
reports 
and other 
screens 
are 


ACCEPTed or DISPLAYed with a single 
command, 
so 


coding 
is simple. 
At execution 
time, 
related 
data 


items can be keyed, viewed 
together, 
and corrected 


before 
being 
entered 
into the program. 


COBOL-80's 
screen 
handling 
facilities 
are Data Gen- 


eral compatible, 
and learning 
to use the features 
is 


easy. Data 
descriptions 
are 
generally 
of the 
same 
form 
as in other 
sections 
of the 
Data Division. 
The 


screen 
section 
allows 
full screen 
descriptions 
with- 


out forcing 
allocation 
of WORKING-STORAGE 
space 


for unused 
portions 
of the screen. 


On output, 
COBOL's 
extensive 
formatting 
capabili- 


ties prOVide neat, precise reports 
with minimal 
effort. 


COBOL-80's 
CHAIN 
verb 
facilitates 
interactive 
sys- 


tems. Any number 
of separately 
coded 
applications 


or application 
segments 
can be reached 
through 
a 


main 
menu. These 
menu-driven 
applications 
which 


make 
ideal 
use of COBOL-80's 
interactive 
capabili- 


ties, allow 
smooth 
transfer 
of control 
from 
one pro- 


gram 
to another. 
With 
CHAIN, 
control 
is transferred 
from the menu program 
to any executable 
module 
as 


specified 
at runtime. 
COBOL-80 
programs 
can also 


CALL 
COBOL-80 
subprograms 
or 
Microsoft 


FORTRAN-80 
or assembly 
language 
subroutines. 
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COBOL-80 
aims 
for 
simplicity 
and 
speed 
in data 


retrieval. 
COBOL-80 
offers 
four kinds of files, so data 


storage 
can aptly 
correspond 
to the application 
for 


'which 
it will 
be used. 
Each 
file 
type 
has 
unique 


characteristics: 


The fastest 
possible 


access to test, packed, 
and binary 
data in any 


'combination. 


Text data in line format. 
Compatible 
with the files 


generated 
by many text 


editors. 


Random 
access by record 


number. 
Direct 
disk 


access 
makes relative files 


extremely 
fast, yet data 


can be accessed 
in any 


sequence, 
deleted 
or 


updated 
interactively, 
and 


cross-referenced 
by key 


across files. 


The most powerful 
data 


access 
method 
available 


from any data processing 
language 
in anyenviron- 


ment. A field within 
each 


record 
is chosen 
as a 


key, and the value of this 
key identifies 
a record 
to 


be read, written, 
updated, 
or deleted. 


COBOL-80's 
program 
segmentation 
capability 


makes 
maximum 
use of 
memory 
when 
large 
pro- 


grams are executed. 
Segmentation 
brings 
individual 


program 
sections 
into memory 
as they are needed. 


This allows 
execution 
of programs 
whose 
size may 


exceed 
machine 
memory 
by several 
times. 
Program 


segmentation 
is easily 
implemented 
by assigning 
a 


single 
number 
to each program 
section 
which 
indi- 


cates whether 
the section 
is to be resident 
in memory 


or overlaid 
during 
execution. 
Any section 
to be over- 


laid is automatically 
read into a preallocated 
section 


of memory 
during 
execution. 


Microsoft COBOL-80 and 
the ANSI Standard 


Features 
of 
Microsoft 
COBOL 


All of Level 1, plus these 
features 
of Level 2: 


CONDITIONS: 


Level 88 conditions 


with value series or range 
Use of logical 


AND/OR/NOT 
in 


conditions 


Use of algebraic 
relational 
symbols 


«,>,=) 


Implied 
subject, 
or 
both subject 
and 


relation, 
in relational 


conditions 


Sign Test 
Nested IF statements; 
parentheses 
in 


conditions 


VERBS: 


Extensions 
to the 


functions 
of ACCEPT 


and DISPLAY for 
formatted 
screen 


handling 


ACCEPTance 
of data 
from DATE/DAY/TIME 


STRING and 


UNSTRING 
statements 


COMPUTE 
with 
multiple 
receiving 


fields 


PERFORM 
VARYING 


IDENTIFIERS: 


Mnemonic-names 
for 


ACCEPT or DISPLAY 
devices 


Procedure-names 


consisting 
of digits 


only 


Qualification 
of names 
(in Procedure 
Division 


statements 
onlvl 
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Sequential, 
All of Level 1 plus these 
Library 
Level 1 


Relative, 
features 
of Level 2: 
Inter-Program 
Level 1 
and Indexed 
I/O 
Communication 
RESERVE clause 
Table Handling 
All of Level 1 
Multiple 
operands 
in 
Full Level 2 formats 
for 
OPEN & CLOSE, with 
SEARCH 
statement 


individual 
options 
per file 
Debugging 
Special 
extensions 
to 
Value of FILE-ID is data- 
name 
ANSI-74 Standard 
providing 
convenient 


Sequential 
I/O 
EXTEND mode for OPEN 
trace style debugging. 


WRITE ADVANCING 
data 
Conditional 
Compilation: 


name lines 
lines with 
"D in column 


LINAGE phrase 
and AT 
7" are bypassed 
unless 


END-OF-PAGE 
clause 
"WITH DEBUGGING 


Relative and 
DYNAMIC 
access 
mode 
MODE" 
is given 
in 


Indexed 
I/O 
(with 
READ NEXT) 
SOURCE-COMPUTER 


START (with 
key 
paragraph. 


relationals 
EQUAL, 
Segmentation 
Level 1 
GREATER, 
or NOT LESS) 


COBOL-BO 
includes 
the 
Microsoft 
Utility 
Software 
Package. 
The Utility 
Software 
Package 
includes 
the 


MACRO-BO 
macro 
assembler, 
the 
L1NK-BO linking 


loader, 
and 
the 
CREF-BO Cross-Reference 
Facility. 


Refer to the description 
of the Utility 
Software 
Pack- 
age for full details. 


The COBOL-hosted 
version 
of M/SORT 
(M/SORT-C) 


is a record-sorting 
facility 
available 
to the program- 


mer through 
the 
1974 ANSI COBOL 
SORT/MERGE 


statements. 
For M/SORT-C, 
the source 
of the input 


records 
may be one or' a set of disk files; or, records 


may 
be constructed 
in memory 
by a user-written 


COBOL procedure 
and RELEASED 
to M/SORTone 
at 


a time. 


Similarly, 
the sorted 
output 
records 
may be automati- 


cally written 
to a disk file; or, records 
may be left in 


memory 
for 
processing 
by a user-written 
OUTPUT 


PROCEDURE 
within 
the COBOL 
program. 
M/SORT- 


C can load an indexed 
sequential 
file. 


M/SORT-C provides 
for a special 
SORT STATUS reg- 


ister 
which 
can 
collect 
and 
return 
any 
errors 


encountered 
during 
a sort. 


COBOL-BO requires 
about 40K bytes of user memory 


in addition 
to the operating 
system's 
space. COBOL 


object 
programs 
will run on systems 
as small as 32K 


bytes. 


Required Hardware 


Intellec 
Microcomputer 
Development 
System 


-Model 
BOOor 


-Series 
II 


-iPDS 
(Personal 
Development 
System) 
-minimum 
of 1 diskette 
drive 


CP/M* Operating 
System or MP/M-II* 
Operating 


System. 


One 
copy 
of 
each 
manual 
is provided 
with 
the 


software 
package. 


Description 


COBOL-80 
Reference 
Manual 
COBOL-80 
User's Guide 
Microsoft 
Utility 
Software 
Manual 


M/SORT 
Reference 
Manual 
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Shipping Media 


(Specify 
by Alpha 
Character 
when 
ordering.) 


A-Single 
density 
(Intellec 
compatible, 
IBM 3740/1 format) 


B-Double 
density 
(Intellec 
compatible, 
M2FM format) 


F-Double-sided, 
Double 
Density, 
5% " diskette 
(iPDS format) 


Order 
Code 


SD104CPMSOA 


SD104CPMSOB 


SD104CPMSOF 


Description 


Microsoft 
COBOL-SO Software 
Package, 
CP/M version 
(Single-Density 
Diskette) 


Microsoft 
COBOL-SO Software 
Package, 
CP/M version 
(Double-Density 
Diskette) 


Microsoft 
COBOL-SO Software 
Package, 
CP/M version 
(iPDS Format) 


Intel offers 
several levels of support 
for this product, 
depending 
on the system configuration 
in which 
it is used. 
Please consult 
the price 
list for a detailed 
description 
of the support 
options 
available. 


An Intel Software 
License 
required. 
'Microsoft 
is a trademark 
of Microsoft, 
Inc. 


'CP/M is a registered 
trademark 
of Digital Research, Inc. 


'MP/M-II 
is a trademark 
of Digital Research, Inc. 
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• Full ANSI standard 
FORTRAN X3.9-1966 
(except the complex data type) 


• Provides numerous enhancements to 
the 1966 ANSI standard 


• Complies several hundred statements 
per minute in a single pass 


• Optimizes the generated object code 
by common subexpression elimination, 
peephole optimization, constant 
folding, and branch optimizations 


• Provides diagnostic output: descriptive 
error messages, error summaries, and 
fully symbolic listings of generated 
machine language 


• Supplies an extensive library of 
efficient subroutines 


• Supports user-written non-standard I/O 
drivers for each logical unit number to 
interface non-standard devices to 
FORTRAN programs 


Microsoft 
FORTRAN-80 
brings 
the most popular 
science 
and engineering 
programming 
language 
to 8080/8085 
microcomputers. 
FORTRAN-80 
is comparable 
to FORTRAN compilers 
on large mainframes 
and minicomputers. 
The FORTRAN-80 
package 
includes 
full ANSI Standard 
FORTRAN 
X3.9·1966 
except 
the COMPLEX 
data type. 
With this compiler, 
users may take advantage 
of many applications 
programs 
already 
written 
in FORTRAN. 


FORTRAN-80 
enhances 
the 1966 ANSI Standard 
in 
several ways: 


-Single-byte 
LOGICAL 
variables 
which 
can be 
used as integer 
quantities 
in the range + 127 
to -127. 


-DO 
loops which 
use LOGICAL 
variables 
for 
tighter, 
faster execution 
of small loops. 


-Logical 
operations 
on integer 
data .. AND., .OR., 


.NOT., .XOR., can be used for 8-bit, 16-bit, or 
32-bit Boolean 
operations. 


-READIWRITE 
End-of-File 
or Error-Condition 
transfer. 
END=n 
and ERR=n 
(where n is the 


statement 
number) 
can be included 
in READ 
or WRITE statements 
to transfer 
control 
to the 
statement 
specified 
by n when an error or end-of- 
file is detected. 


-ENCODE/DECODE 
for FORMAT operations 
to 
memory. 


-IMPLICIT 
statement 
for redefining 
default 
variable 
types by specifying 
a type and a range of 


initial 
letters. 


-INCLUDE 
sta~ement for including 
commonly 
used 
subroutines, 
code, or declarations 
from another 


file. 


-INTEGER*4 
variables 
and constants 
using 32 bits 
in the range of +2,147,483,647 
to -2,147,483,648. 


-Support 
for CP/M" 
version 
2.x providing 
access 
to a maximum 
of 65,535 random 
records 
in a file 
as large as 8 megabytes. 
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FORTRAN-80 
compiles 
several hundred 
statements 


per minute 
in a single 
pass. It requires 
no more 


than 27K bytes of memory 
to compile 
most 


programs. 
Additional 
memory, 
when available, 
is 


used for symbol 
table storage 
and optimizations. 
Compiled 
programs 
are relocatable 
modules 
that 


are linked and loaded at runtime. 


The FORTRAN-SO compiler 
optimizes 
generated 


object 
code in several ways: 


Common 
Subexpression 
Elimination 


Common 
subexpressions 
are evaluated 
once; 


the value is automatically 
substituted 
in 


subsequent 
occurrences 
of the subexpression. 


Peephole 
Optimization 


In special 
cases, small sections 
of code can 


be replaced 
by more compact 
code. 
Example: 
1=1+1 uses an INX H instruction 


instead of a DAD. 


Constant 
Folding 


Integer constant 
expressions 
are evaluated 
at 


compile 
time. 


Branch 
Optimizations 


The number 
of conditional 
jumps 
in 


arithmetic 
and 10gicailFs 
is minimized. 


The 
compiler 
also 
provides 
diagnostic 
output. 


Descriptive 
error 
messages 
include 
the 
preceding 


twenty 
characters. 
At program's 
end, 
the 
compiler 


generates 
an error summary. 
A fully symbolic 
listing 


of the generated 
machine 
language 
is also produced. 
This is supplemented 
by tables of addresses 
assigned 


to labels, variables, 
and constants. 


FORTRAN-80 
supplies 
an extensive 
library 
of effi- 


cient 
subroutines. 
Only 
the 
necessary 
subroutines 


are loaded 
by the linker at load time. The FORTRAN 


library 
includes 
the following 
Intrinsic 
Functions: 


ABS 
AINT 
ALOG 
ALOG10 
AMAXO 
AMAX1 
AMINO 
AMIN1 
AMOD 
ATAN 
ATAN2 
COS 
DABS 


DATAN 
DATAN2 
DBLE 
DCOS 
DEXP 
DIM 
DLOG 
DLOG10 
DMAX1 
DMIN1 
DMOD 
DSIGN 


DSIN 
DSORT 
EXP 
FIX 
FLOAT 
lABS 


101M 
IDINT 
INP 
INT 
ISIGN 
MAXO 


MAX1 
MIND 
MIN1 
MOD 
OUT 
PEEK 
POKE 
SIGN 
SIN 
SNGL 
SORT 
TANH 


The library 
also contains 
efficient 
routines 
for 16-bit 


and 
32-bit 
integer 
arithmetic 
and 
32-bit 
and 
64-bit 


floating 
point 
arithmetic. 


The 
FORTRAN-80 
package 
includes 
the 
Microsoft 


Utility 
Software 
Package. 
The Utility 
Software 
Pack- 


age includes 
the 
MACRO-80 
macro 
assembler, 
the 


L1NK-80 
linking 
loader, 
and 
the 
CREF-80 
Cross- 


Reference 
Facility. 
Refer 
to 
the 
description 
of the 


Microsoft 
Utility Software 
Package 
for full details. 


Users 
may write 
non-standard 
I/O drivers 
for 
each 


Logical 
Unit 
Number, 
so 
interfacing 
non-standard 


devices to FORTRAN 
programs 
is straightforward. 


The FORTRAN-80 
compiler 
occupies 
approximately 


24K bytes of memory, 
using the CP/M operating 
sys- 


tem. 
Most 
programs 
can 
be compiled 
within 
27K 


bytes of additional 
memory. 
At link time, the L1NK-80 


linking 
loader 
occupies 
about 
14K bytes. The Run- 


time Library 
requires 2K-14K 
bytes, depending 
on the 


type of program 
being 
run. 


Required Hardware 


Intellec 
Microcomputer 
Development 
System 


-Model 
800 or 
-Series 
II 
-iPDS 
(Personal 
Development 
System) 


-minimum 
of 1 diskette 
drive 


CP/M' 
Operating 
System or MP/M-W 
Operating 


System. 
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One 
copy 
of 
each 
manual 
is provided 
with 
the 


software 
package. 


Description 


FORTRAN-80 Reference Manual 
FORTRAN-80 User's Manual 
Microsoft Utility Software Manual 


(Specify 
by Alpha 
Character 
when ordering.) 


A-Single 
density 
(Intellec 
compatible, 


IBM 3740/1 format) 


B-Double 
density 
(Intellec 
compatible, 


M2 FM format) 


F-Double-sided, 
Double 
Density 
5%" 


Floppy 
(iPDS format) 


Order Code 


SD103CPM80A 


SD103CPM80B 


SD103CPM80F 


Description 


Microsoft 
FORTRAN-80 
Software 
Package, 
CP/M version 
(Single-Density 
Diskette) 


Microsoft 
FORTRAN-80 
Software 
Package, 
CP/M version 
(Double-Density 
Diskette) 


Microsoft 
FORTRAN-80 
Software 
Package, 
CP/M version 
(iPDS Format) 


Intel offers 
several levels of support 
for this product, 
depending 
on the system configuration 
in which 
it is 


used. 
Please 
consult 
the 
price 
list 
for 
a detailed 


description 
of the support 
options 
available. 


An Intel Software license required. 
·Microsoft 
is a trademark of Microsoft, Inc. 
·CP/M is a registered trademark of Digital Research, Inc. 
·MP/M-II is a trademark of Digital Research, Inc. 
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MICROSOFT*, INC. BASIC-86 INTERPRETER 
SOFTWARE PACKAGE 


• Compatible with other Microsoft BASIC 


compilers and interpreters 


• Sophisticated string handling and 


structured programming features for 
applications development 


• Direct transfer of BASIC programs to 


the 8080, 8085 and 8088 


• Random and sequential file 


manipulation where random file record 
length is user-definable 


• Read or write memory location 


capabilities 


• Meets the requirements for the ANSI 


subset standard .or BASIC, and 
supports many enhancements 


• Extensive text editing features built-In 


• Automatic line number generation and 


renumbering 


• Supports assembly language 
subroutine calls 


• Trace facilities for easier debugging 


BASIC Release 5.0 from 
Microsoft 
is an extensive 
implementation 
of BASIC. Microsoft 
BASIC gives users what 
they 
want 
from 
a BASIC-ease 
of use plus 
the 
features 
that 
are comparable 
to a minicomputer 
or large 
mainframe. 


BASIC-86 
meets the requirements 
for the ANSI subset standard 
for BASIC, as set forth 
in document 
BSRX3.6G- 


1978. It supports 
many unique 
features 
rarely found 
in other 
BASICs. 


-Four 
variable 
types: Integer (-32768, 
+32767), 
String 
(up to 255 characters), 
Single-Precision 


Floating 
Point (7 digits), 
Double-Precision 


Floating 
Point (16 digits). 


-Trace 
facilities 
(TRON/TROFF) 
for easier 


debugging. 


-Error 
trapping 
using the ON ERROR GOTO 


statement. 


-PEEK 
and POKE statements 
to read or write any 


memory 
location. 


-Automatic 
line number 
generation 
and 


renumbering, 
including 
referenced 
line numbers. 


-Boolean 
operators 
OR, AND, NOT, XOR, 


EQV, IMP. 


-Formatted 
output 
using the PRINT USING facility, 


including 
asterisk 
fill, floating 
dollar 
sign, 


scientific 
notation, 
trailing 
sign, and comma 


insertion. 


-Direct 
access to I/O ports with the INP and OUT 


functions. 


-Extensive 
program 
editing 
facilities 
via EDIT 


command 
and EDIT mode subcommands. 


-Assembly 
language 
subroutine 
calls (up to 10 per 


program) 
are supported. 


-IF/THEN/ELSE 
and nested IF/THEN/ELSE 


constructs. 


-Supports 
variable-length 
random 
and sequential 


disk files with a complete 
set of file manipulation 


statements: 
OPEN, CLOSE, GET, PUT, KILL, 


NAME, MERGE. 


BASIC-86 Commands, Statements, 
Arithmetic Functions 
Functions 
ABS 
SIN 
LOG 


AUTO 
RENUM 
NAME 
INT 
CDBL 
FIX 


LIST 
WIDTH 
SAVE 
SGN 
CSNG 
COS 


NULL 
CONT 
EDIT 
ATN 
CINT 
RND 


TROFF 
MERGE 
NEW 
EXP 
SQR 
TAN 


CLEAR 
RUN 
TRON 
LOAD 
DELETE 
String Functions 


Program Statements 
ASC 
STR$ 
INSTR 
LEN 
HEX$ 
RIGHT$ 


CALL 
RANDOMIZE 
RETURN 
STRING$ 
OCT$ 
MID$ 


GOSUB 
COMMON 
WAIT 
CHR$ 
VAL 
SPACE$ 


END 
DEF FN 
ON GOSUB 
I 
LEFT$ 


GOTO 
ERROR 
DIM 
STOP 
POKE 
FOR/NEXT/ 
Operators 
WHILE! 
RESUME 
STEP 
WEND 
SWAP 
IFITHEN/ 
XOR 
CHAIN 
DEFDBL 
ELSE 
f\ 
<= 
NOT 
DEF USR 
DEFSTR 
ON ERROR 
< 
EQV 
LET 
DEFSNG 
GOTO 
> 
<> 
MOD 
REM 
DEFINT 
OPTION BASE 
IMP 
OR 
Input/Output Statements and Functions 
AND 


CLOSE 
GET 
NAME 
Special Functions 
KILL 
POS 
PUT 
OUT 
FIELD 
EOF 
ERL 
ERR 
VARPTR 
RESTORE 
LSET/RSET 
SPC 
USR 
FRE 
PEEK 
READ 
PRINT 
INKEY$ 
TAB 
USING 
INPUT 
DATA 
LOC 
OPEN 
LINE 
MKI$ 
CVD 
INPUT 
MKS$ 
CVI 
PRINT 
MKD$ 
CVS 
WRITE 
LLiST 
LPRINT 
LPOS 


CP/M-86* 
Operating 
System 
or MP/M-86* 
Operating 
System. 


The 
standard 
disk 
version 
of 
Microsoft 
BASIC-86 
occupies 
32K bytes of memory. 
Microsoft 
BASIC-86 
Interpreter 
is compatible 
with 
the CP/M-86* 
operat- 
ing system. 


Required Hardware 


Microsoft 
BASIC-86 
Interpreter 
will operate 
with any 
currently 
supported 
configuration 
of 
CP/M-86 
or 
MP/M-86*. 


One 
copy 
of 
each 
manual 
is provided 
with 
the 
software 
package. 


Description 


BASIC-86 
Reference 
Manual 
BASIC 
Reference 
Book 


(Please specify by Alpha Character when ordering.) 


A-Single 
Density (Intellec compatible, 
IBM 3740/1 format) 


Order Code 


SD203CPM86A 


Description 


Microsoft 
BASIC-86 Interpreter 
Software Package, CP/M-86 version (Single-Density 
Diskette) 


Microsoft 
BASIC-86 Interpreter 
Software Package, 
iRMX/86 version (Single-Density 
Diskette) 


Intel offers several levels of support for this product, 
depending 
on the system configuration 
in which it is 


used. 
Please consult 
the 
price 
list for a detailed 


description 
of the support 
options 
available. 


An Intel Software License required. 
"Microsoft 
is a trademark of Microsoft, Inc. 


"CP/M-86 is a registered trademark of Digital Research, Inc. 
"MP/M-86 is a trademark of Digital Research. Inc. 


JOVIAL-86 
CROSS-COMPILER 


• DEC*-10 host (TOPS-10 O/S) 


• IBM 370, 3033, 4341 host (OS/MVS) 


• Full MIL-STD-1589B language 
implementation 


• Extensively optimized object code 


• Supports IEEE floating-point math with 
8087 coprocessor 


• RAM/ROM separation of constants and 
code supported 


• Object compatible and linkable with 
Intel's languages for 8086/8088 


• Generates source symbols, lines and 
type information for debugging with 
ICE™·86A and PSCOPE™ 


• Type-checking of parameters between 
modules optionally enforced by the 
linker 


• Choice of silicon or software 
implementation for floating point 


JOVIAL was developed 
in the late 1950s by Jules Schwartz 
and colleagues to aid in programming 
large complex 
realtime 
systems. The language 
was adopted 
by the U.S. Air Force in 1967 and its use is now required 
for 
programming 
of all avionics embedded 
computer 
systems. 


Intel's JOVIAL Compiler 
implements 
the latest published 
standard 
of this language 
(MIL-STD-1589B) 
for iAPX 
86/20 
16-bit 
microprocessors. 
Intel's 
implementation 
of J73 offers 
a complete 
solution 
for 
programming 
applications 
in JOVIAL from compiling 
modules on the mainframe 
to downloading 
software 
to Intel's Series III 
development 
system 
where 
a host 
of JOVIAL-86-compatible 
languages, 
relocation 
and 
linkage 
software, 


symbolic 
debuggers 
and an in-circuit 
emulator 
(ICE-86A) are available. 


The JOVIAL 
language 
was designed 
for 
program- 
ming large complex 
realtime systems. The language 
is a derivative 
of IAL (International 
Algebraic 
Lan- 
guage) and has borrowed 
compound 
statement 
and 
control structures 
from it. JOVIAL supports 
fixed and 
floating-point, 
signed 
and 
unsigned 
integers, 
strings, 
tables, status items and bits. The language 
provides 
access to almost any configuration 
of logi- 
calor 
arithmetic 
values including 
packed structures 
of 
flexible 
description. 
The 
communication 
pool 
(COMPOOL) 
permits 
sharing 
of system data among 
many subprograms 
by providing 
a centralized 
data 
and procedure 
description 
which 
enforces 
uniform 
usage and simplifies 
centralized 
configuration 
man- 
agement 
of a JOVIAL system data base. 


The JOVIAL-86 compiler 
operates in multiple 
passes. 
The front-end 
phase analyzes the input program 
and 


translates 
it into 
an 
intermediate 
language. 
The 
global 
optimizer 
phase 
analyzes 
the 
intermediate 
code 
and applies 
extensive 
optimizations 
such 
as 
constant 
and value folding, 
multiply 
distribution 
and 
operator 
reassociation 
for efficient 
address 
calcula- 
tion, compile 
time short-cut 
booleans, 
unreachable 
code deletion, 
and unnecessary 
store suppression. 
The 
code 
generator 
phase 
generates 
relocatable 
object code from this intermediate 
code. Other func- 


tions in the final phase are responsible 
for generat- 
ing listings 
and COMPOOL output. 


The compiler 
supports 
development 
of complex 
and 
large 
applications 
by providing 
a comprehensive 
cross-reference 
listing 
that 
identifies 
the statement 
number where the variable is set. JOVIAL-86 can also 
generate 
a statistical 
listing showing 
the distribution 
of various 
symbol 
table 
classes 
and 
intermediate 
language 
operators. 
The assembly 
language 
output 
listing 
displays 
the 
object 
program 
in assembly 
mnemonics. 
Optionally, 
the compiler 
can produce 
a 
reformatted 
source 
program. 


JOVIAL-86 
CROSS-COMPILER 


The JOVIAL source 
programs 
may be developed 
and 


maintained 
on the 
mainframe 
IBM 370 or DEC-10 


(and 
compatible 
computers), 
or 
alternately, 
the 


source 
programs 
may be created 
and maintained 
on 


the 
Intellec 
Series 
III Microcomputer 
Development 


System, 
sent to the mainframe 
for compilation 
and 


brought 
back to the Series 
III for further 
processing. 


This processing 
includes 
relocating, 
linking, 
debug- 


ging, 
emulating 
and 
executing. 
The ONLINE 
utility 


allows 
the 
Series 
III to 
act 
as a terminal 
to 
the 


mainframe 
to edit and examine 
files, etc. The transfer 


of source 
and 
object 
files 
between 
the 
mainframe 


and 
the 
Series 
III is accomplished 
with 
either 
the 


2780/3780 
emulator 
or the 
upload/download 
soft- 
ware on the Series 
III. 


SPECIFICATIONS 


Operating 
Environment 


Intel's 
JOVIAL-86 
compiler 
runs under 
MVS on IBM 


370 and 
requires 
a minimum 
750 Kb partition. 
The 


DEC-10 version 
runs under 
TOPS-10 
operating 
sys- 


tem and requires 
100K words. 


Required 
Hardware 


- 
DEC-10, IBM 370 or compatible 
computer 


- 
Intellec 
Series 
III Microcomputer 
Development 


System 
- 
Necessary 
Modems 
and Cables for Serial 
Link 


Required 
Software 


- 
Series 
III Operating 
System 


- 
IAPX86 Family 
Utilities 


Optional 
Software 


- 
Mainframe 
Link (2780/3780 
Emulator) 


The 
object 
code 
produced 
by the 
compiler 
is in 
Intel's 
standard 
object 
module 
format 
and is, there- 


fore, compatible 
with 
standard 
Series 
III utilities 
like 


L1NK86, LOC86, 
L1B86 and 
OH86. 
Adequate 
com- 


patibility 
with 
subprograms 
written 
in PASCAL86, 


FORTRAN86, 
ASM86 
annd 
PL/M-86 
is assured 
by 


following 
consistent 
and 
well-documented 
param- 


eter 
passing 
and 
register 
usage 
conventions. 
The 


compiler 
generates 
source 
program 
symbols, 
lines 


and 
type 
information 
in the 
object 
code 
to 
allow 


symbolic 
debugging 
with the Series III debugger 
and 


in-circuit 
emulator. 


The 
compiler 
generates 
8087 
instructions 
for 


floating-point 
operations. 
In the absence 
of the 8087 


processor, 
the 8087 emulator 
software 
may be linked 


with 
the 
JOVIAL 
program 
to execute 
the 
floating- 


point 
instructions. 


Documentation 
Package 


One 
copy 
of 
each 
manual 
is provided 
with 
the 


software 
package. Additional 
copies may be ordered. 


Part No. 
Description 


121886 
JOVIAL 
Language 
Specification 


121887 
JOVIAL-86 
User's Guide 
172174 
Asynchronous 
Communications 
Link 


User's Guide 
(DEC-10 only) 


Shipping 
Media 


One phase-encoded, 
1600 B.P.1.Magnetic 
Tape 


- 
JOVIAL-86 
Compiler 
Object 
Code (DEC-10 and 
IBM) 
- 
Asynchronous 
Communications 
Link Software 


(DEC-10 only) 
One Single- and one Double-Density 
Diskette 
(ISIS II) 


- 
JOVIAL-86 
Run Time Library 
(DEC-10 and IBM) 


- 
Asynchronous 
Communications 
Link Software 


(DEC-10 only) 
- 
On-line 
Utilities 
(DEC-10 and IBM) 


ORDERING INFORMATION 


Order Code 
Description 


SD900TOP86 
JOVIAL-86 
Cross-Compiler 
Package 
for DECsYSTEM.10· 


SD900MVS86 
JOVIAL-86 
Cross-Compiler 
Package 
for IBM 370 


Requires 
Software 
License 


'DEC and DECsYSTEM-l0 
are registeredtrademarksof Digital Equipment Corporation. 


SUPPORT 


Hotline 
Telephone 
Support, 
Software 
Performance 
Report 
(SPR), Software 
Updates, 
and Monthly 
Technical 
Newsletters 
are available. 


